aboutsummaryrefslogtreecommitdiffstats
path: root/net/irda
diff options
context:
space:
mode:
authorPeter Zijlstra <a.p.zijlstra@chello.nl>2006-11-21 20:33:01 -0500
committerDavid S. Miller <davem@davemloft.net>2006-11-21 20:33:01 -0500
commit700f9672c9a61c12334651a94d17ec04620e1976 (patch)
tree7b78a376a8a1001642338f5576fc9aeccf87546f /net/irda
parent4498c80d9c1ebdf42837be6a52ead35a2aa2b819 (diff)
[IRDA]: Lockdep fix.
On Sat, 2006-11-18 at 16:12 +0300, Andrey Borzenkov wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 2.6.19-rc5-2avb #2 > - --------------------------------------------- > pppd/26425 is trying to acquire lock: > (&hashbin->hb_spinlock){....}, at: [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 > [irda] > > but task is already holding lock: > (&hashbin->hb_spinlock){....}, at: [<dfdea857>] irlmp_slsap_inuse+0x37/0x170 > [irda] > > other info that might help us debug this: > 1 lock held by pppd/26425: > #0: (&hashbin->hb_spinlock){....}, at: [<dfdea857>] > irlmp_slsap_inuse+0x37/0x170 [irda] > > stack backtrace: > [<c010413c>] dump_trace+0x1cc/0x200 > [<c010418a>] show_trace_log_lvl+0x1a/0x30 > [<c01047f2>] show_trace+0x12/0x20 > [<c01048c9>] dump_stack+0x19/0x20 > [<c01346ca>] __lock_acquire+0x8fa/0xc20 > [<c0134d2d>] lock_acquire+0x5d/0x80 > [<c02a851c>] _spin_lock+0x2c/0x40 > [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 [irda] > [<dfdebab2>] irlmp_open_lsap+0x62/0x180 [irda] > [<dfdf35d1>] irttp_open_tsap+0x181/0x230 [irda] > [<dfdc0c3d>] ircomm_open_tsap+0x5d/0xa0 [ircomm] > [<dfdc05d8>] ircomm_open+0xb8/0xd0 [ircomm] > [<dfdd0477>] ircomm_tty_open+0x4f7/0x570 [ircomm_tty] > [<c020bbe4>] tty_open+0x174/0x340 > [<c016bd69>] chrdev_open+0x89/0x170 > [<c0167bd6>] __dentry_open+0xa6/0x1d0 > [<c0167da5>] nameidata_to_filp+0x35/0x40 > [<c0167df9>] do_filp_open+0x49/0x50 > [<c0167e47>] do_sys_open+0x47/0xd0 > [<c0167f0c>] sys_open+0x1c/0x20 > [<c010307d>] sysenter_past_esp+0x56/0x8d > [<b7f86410>] 0xb7f86410 > ======================= The comment at the nesting lock says: /* Careful for priority inversions here ! * irlmp->links is never taken while another IrDA * spinlock is held, so we are safe. Jean II */ So, under the assumption the author was right, it just needs a lockdep annotation. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/irda')
-rw-r--r--net/irda/irlmp.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/net/irda/irlmp.c b/net/irda/irlmp.c
index 5073261b9d0c..fede83763095 100644
--- a/net/irda/irlmp.c
+++ b/net/irda/irlmp.c
@@ -1678,7 +1678,8 @@ static int irlmp_slsap_inuse(__u8 slsap_sel)
1678 * every IrLAP connection and check every LSAP associated with each 1678 * every IrLAP connection and check every LSAP associated with each
1679 * the connection. 1679 * the connection.
1680 */ 1680 */
1681 spin_lock_irqsave(&irlmp->links->hb_spinlock, flags); 1681 spin_lock_irqsave_nested(&irlmp->links->hb_spinlock, flags,
1682 SINGLE_DEPTH_NESTING);
1682 lap = (struct lap_cb *) hashbin_get_first(irlmp->links); 1683 lap = (struct lap_cb *) hashbin_get_first(irlmp->links);
1683 while (lap != NULL) { 1684 while (lap != NULL) {
1684 IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;); 1685 IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;);