summaryrefslogtreecommitdiff
path: root/fs/9p/v9fs.c
diff options
context:
space:
mode:
authorZach Brown <zach.brown@oracle.com>2006-07-04 09:57:52 (GMT)
committerLinus Torvalds <torvalds@g5.osdl.org>2006-07-04 17:24:57 (GMT)
commita46f9484f8926aacb2e79a0e1676de3a6a6fbae8 (patch)
tree21d90306af4677091547465c1ba02e0545276d1a /fs/9p/v9fs.c
parentdd8041f16b117f63f40fb844d6cdebe8b03514d2 (diff)
downloadlinux-a46f9484f8926aacb2e79a0e1676de3a6a6fbae8.tar.xz
[PATCH] mthca: initialize send and receive queue locks separately
mthca: initialize send and receive queue locks separately lockdep identifies a lock by the call site of its initialization. By initializing the send and receive queue locks in mthca_wq_init() we confuse lockdep. It warns that that the ordered acquiry of both locks in mthca_modify_qp() is recursive acquiry of one lock: ============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- modprobe/1192 is trying to acquire lock: (&wq->lock){....}, at: [<f892b4db>] mthca_modify_qp+0x60/0xa7b [ib_mthca] but task is already holding lock: (&wq->lock){....}, at: [<f892b4ce>] mthca_modify_qp+0x53/0xa7b [ib_mthca] Initializing the locks separately in mthca_alloc_qp_common() stops the warning and will let lockdep enforce proper ordering on paths that acquire both locks. Signed-off-by: Zach Brown <zach.brown@oracle.com> Cc: Roland Dreier <rolandd@cisco.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/9p/v9fs.c')
0 files changed, 0 insertions, 0 deletions