* 2.6.19-rc5: lockdep warnings starting irattach
@ 2006-11-18 13:12 Andrey Borzenkov
2006-11-20 9:04 ` Peter Zijlstra
2006-11-20 9:15 ` [PATCH] lockdep: annotate irda warning Peter Zijlstra
0 siblings, 2 replies; 5+ messages in thread
From: Andrey Borzenkov @ 2006-11-18 13:12 UTC (permalink / raw)
To: samuel; +Cc: irda-users, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I experimented with SyncCE; after starting IrDA I got this:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ip_tables: (C) 2000-2006 Netfilter Core Team
=============================================
[ 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
=======================
This apparently happens when irattach is run. Interface itself (irda0) is
created as far as I can tell.
Please let me know if additional information is required.
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFXwbDR6LMutpd94wRAiUpAJwIK5hSusOwFUloh0jXOb5hk5iVwgCfX7Iq
c5kRWItPWR9WGw4jORPd21k=
=oax8
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: 2.6.19-rc5: lockdep warnings starting irattach 2006-11-18 13:12 2.6.19-rc5: lockdep warnings starting irattach Andrey Borzenkov @ 2006-11-20 9:04 ` Peter Zijlstra 2006-11-20 9:12 ` Ingo Molnar 2006-11-20 9:15 ` [PATCH] lockdep: annotate irda warning Peter Zijlstra 1 sibling, 1 reply; 5+ messages in thread From: Peter Zijlstra @ 2006-11-20 9:04 UTC (permalink / raw) To: Andrey Borzenkov, Andrew Morton Cc: samuel, irda-users, linux-kernel, Ingo Molnar, arjan 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. (depends on patches in -mm for spin_lock_irqsave_nested()) Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- net/irda/irlmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-mm/net/irda/irlmp.c =================================================================== --- linux-2.6-mm.orig/net/irda/irlmp.c 2006-11-20 09:54:50.000000000 +0100 +++ linux-2.6-mm/net/irda/irlmp.c 2006-11-20 09:57:39.000000000 +0100 @@ -1678,7 +1678,7 @@ static int irlmp_slsap_inuse(__u8 slsap_ * every IrLAP connection and check every LSAP associated with each * the connection. */ - spin_lock_irqsave(&irlmp->links->hb_spinlock, flags); + spin_lock_irqsave_nested(&irlmp->links->hb_spinlock, flags, 1); lap = (struct lap_cb *) hashbin_get_first(irlmp->links); while (lap != NULL) { IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;); ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 2.6.19-rc5: lockdep warnings starting irattach 2006-11-20 9:04 ` Peter Zijlstra @ 2006-11-20 9:12 ` Ingo Molnar 0 siblings, 0 replies; 5+ messages in thread From: Ingo Molnar @ 2006-11-20 9:12 UTC (permalink / raw) To: Peter Zijlstra Cc: Andrey Borzenkov, Andrew Morton, samuel, irda-users, linux-kernel, arjan * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > 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. > > (depends on patches in -mm for spin_lock_irqsave_nested()) > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Ingo Molnar <mingo@elte.hu> Ingo ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] lockdep: annotate irda warning 2006-11-18 13:12 2.6.19-rc5: lockdep warnings starting irattach Andrey Borzenkov 2006-11-20 9:04 ` Peter Zijlstra @ 2006-11-20 9:15 ` Peter Zijlstra 2006-11-24 20:14 ` Samuel Ortiz 1 sibling, 1 reply; 5+ messages in thread From: Peter Zijlstra @ 2006-11-20 9:15 UTC (permalink / raw) To: Andrey Borzenkov, Andrew Morton Cc: samuel, irda-users, linux-kernel, Ingo Molnar, arjan (repost with slightly changed patch) 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. (depends on patches in -mm for spin_lock_irqsave_nested()) Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- net/irda/irlmp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6-mm/net/irda/irlmp.c =================================================================== --- linux-2.6-mm.orig/net/irda/irlmp.c 2006-11-20 09:54:50.000000000 +0100 +++ linux-2.6-mm/net/irda/irlmp.c 2006-11-20 10:12:11.000000000 +0100 @@ -1678,7 +1678,8 @@ static int irlmp_slsap_inuse(__u8 slsap_ * every IrLAP connection and check every LSAP associated with each * the connection. */ - spin_lock_irqsave(&irlmp->links->hb_spinlock, flags); + spin_lock_irqsave_nested(&irlmp->links->hb_spinlock, flags, + SINGLE_DEPTH_NESTING); lap = (struct lap_cb *) hashbin_get_first(irlmp->links); while (lap != NULL) { IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;); ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] lockdep: annotate irda warning 2006-11-20 9:15 ` [PATCH] lockdep: annotate irda warning Peter Zijlstra @ 2006-11-24 20:14 ` Samuel Ortiz 0 siblings, 0 replies; 5+ messages in thread From: Samuel Ortiz @ 2006-11-24 20:14 UTC (permalink / raw) To: Peter Zijlstra Cc: Andrey Borzenkov, Andrew Morton, irda-users, linux-kernel, Ingo Molnar, arjan, John Platt Hi guys, On Mon, Nov 20, 2006 at 10:15:39AM +0100, Peter Zijlstra wrote: > > So, under the assumption the author was right, it just needs a lockdep > annotation. > > (depends on patches in -mm for spin_lock_irqsave_nested()) > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> > --- > net/irda/irlmp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux-2.6-mm/net/irda/irlmp.c > =================================================================== > --- linux-2.6-mm.orig/net/irda/irlmp.c 2006-11-20 09:54:50.000000000 +0100 > +++ linux-2.6-mm/net/irda/irlmp.c 2006-11-20 10:12:11.000000000 +0100 > @@ -1678,7 +1678,8 @@ static int irlmp_slsap_inuse(__u8 slsap_ > * every IrLAP connection and check every LSAP associated with each > * the connection. > */ > - spin_lock_irqsave(&irlmp->links->hb_spinlock, flags); > + spin_lock_irqsave_nested(&irlmp->links->hb_spinlock, flags, > + SINGLE_DEPTH_NESTING); > lap = (struct lap_cb *) hashbin_get_first(irlmp->links); > while (lap != NULL) { > IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;); This patch got pushed into mainline, while the spin_lock_irq_save_nested() patches are not there yet. It breaks IrDA as irlmp.c doesn't build. Linus, could you please revert the corresponding commit (700f9672c9a61c12334651a94d17ec04620e1976) unless you are planning to pull the spin_lock_irq_save_nested() patches soon from -mm ? Thanks a lot in advance. Cheers, Samuel. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-11-24 20:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-11-18 13:12 2.6.19-rc5: lockdep warnings starting irattach Andrey Borzenkov 2006-11-20 9:04 ` Peter Zijlstra 2006-11-20 9:12 ` Ingo Molnar 2006-11-20 9:15 ` [PATCH] lockdep: annotate irda warning Peter Zijlstra 2006-11-24 20:14 ` Samuel Ortiz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox