2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Miles Lane]

I have patches for hostap, pcmcia and lockdep applied to this kernel.
These patches are the ones resulting from several recent message
threads.
I just noticed this in my kernel log:

[ INFO: possible recursive locking detected ]
---------------------------------------------
multiload-apple/2820 is trying to acquire lock:
 (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>]
sock_def_readable+0x15/0x69

but task is already holding lock:
 (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>]
sock_def_readable+0x15/0x69

other info that might help us debug this:
3 locks held by multiload-apple/2820:
 #0:  (rtnl_mutex){--..}, at: [<c120028e>] mutex_lock+0x1c/0x1f
 #1:  (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>]
sock_def_readable+0x15/0x69
 #2:  (&priv->lock){.+..}, at: [<f90472c9>]
ipw_irq_tasklet+0x54/0x10c1 [ipw2200]

stack backtrace:
 [<c1003502>] show_trace_log_lvl+0x54/0xfd
 [<c1003b6a>] show_trace+0xd/0x10
 [<c1003c0e>] dump_stack+0x19/0x1b
 [<c102ccd6>] __lock_acquire+0x755/0x970
 [<c102d1b6>] lock_acquire+0x60/0x80
 [<c1201533>] _read_lock+0x23/0x32
 [<c119d8db>] sock_def_readable+0x15/0x69
 [<c11b5621>] netlink_broadcast+0x1c6/0x2b8
 [<c11ad712>] wireless_send_event+0x28a/0x29c
 [<f9047d02>] ipw_irq_tasklet+0xa8d/0x10c1 [ipw2200]
 [<c101a4e7>] tasklet_action+0x45/0x76
 [<c101a709>] __do_softirq+0x55/0xb0
 [<c1004a64>] do_softirq+0x58/0xbd
 [<c101a6a8>] irq_exit+0x3f/0x4b
 [<c1004b89>] do_IRQ+0xc0/0xcf
 [<c1002fd9>] common_interrupt+0x25/0x2c

Re: 2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]


* Miles Lane <miles.lane@gmail.com> wrote:

> I have patches for hostap, pcmcia and lockdep applied to this kernel. 
> These patches are the ones resulting from several recent message 
> threads. I just noticed this in my kernel log:
> 
> [ INFO: possible recursive locking detected ]
> ---------------------------------------------

ok, lockdep should allow same-class read-lock recursion too, because 
it's used by real code and is being relied upon. Could you try the patch 
below? (if you have CONFIG_DEBUG_LOCKING_API_SELFTESTS enabled then 
apply the other attached patch as well, to fix two testcases.)

        Ingo

---------------->
Subject: lockdep: allow read_lock() recursion of same class
From: Ingo Molnar <mingo@elte.hu>

lockdep so far only allowed read-recursion for the same lock
instance. This is enough in the overwhelming majority of cases,
but a hostap case triggered and reported by Miles Lane relies
on same-class different-instance recursion. So we relax the
restriction on read-lock recursion.

(this change does not allow rwsem read-recursion, which is
 still forbidden.)

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/lockdep.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: linux/kernel/lockdep.c
===================================================================
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -843,10 +843,9 @@ check_deadlock(struct task_struct *curr,
 			continue;
 		/*
 		 * Allow read-after-read recursion of the same
-		 * lock instance (i.e. read_lock(lock)+read_lock(lock)):
+		 * lock class (i.e. read_lock(lock)+read_lock(lock)):
 		 */
-		if ((read == 2) && prev->read &&
-				(prev->instance == next_instance))
+		if ((read == 2) && prev->read)
 			return 2;
 		return print_deadlock_bug(curr, prev, next);
 	}

[-- Attachment #2: lockdep-locking-api-self-tests-read-recursion-update.patch --]
[-- Type: text/plain, Size: 1596 bytes --]

Subject: lockdep: locking API self-tests, read-recursion update
From: Ingo Molnar <mingo@elte.hu>

lockdep now allows same type (different instance) rwlock recursion
too, update the testcases accordingly.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 lib/locking-selftest.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux/lib/locking-selftest.c
===================================================================
--- linux.orig/lib/locking-selftest.c
+++ linux/lib/locking-selftest.c
@@ -248,7 +248,7 @@ GENERATE_TESTCASE(AA_rsem)
 
 /*
  * Special-case for read-locking, they are
- * allowed to recurse on the same lock instance:
+ * allowed to recurse on the same lock class:
  */
 static void rlock_AA1(void)
 {
@@ -259,7 +259,7 @@ static void rlock_AA1(void)
 static void rlock_AA1B(void)
 {
 	RL(X1);
-	RL(X2); // this one should fail
+	RL(X2); // this one should NOT fail
 }
 
 static void rsem_AA1(void)
@@ -1132,7 +1132,7 @@ void locking_selftest(void)
 	init_shared_classes();
 	debug_locks_silent = !debug_locks_verbose;
 
-	DO_TESTCASE_6("A-A deadlock", AA);
+	DO_TESTCASE_6R("A-A deadlock", AA);
 	DO_TESTCASE_6R("A-B-B-A deadlock", ABBA);
 	DO_TESTCASE_6R("A-B-B-C-C-A deadlock", ABBCCA);
 	DO_TESTCASE_6R("A-B-C-A-B-C deadlock", ABCABC);
@@ -1153,7 +1153,7 @@ void locking_selftest(void)
 
 	print_testname("recursive read-lock #2");
 	printk("             |");
-	dotest(rlock_AA1B, FAILURE, LOCKTYPE_RWLOCK);
+	dotest(rlock_AA1B, SUCCESS, LOCKTYPE_RWLOCK);
 	printk("             |");
 	dotest(rsem_AA1B, FAILURE, LOCKTYPE_RWSEM);
 	printk("\n");

Re: 2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Miles Lane <miles.lane@gmail.com> wrote:
> 
> > I have patches for hostap, pcmcia and lockdep applied to this kernel. 
> > These patches are the ones resulting from several recent message 
> > threads. I just noticed this in my kernel log:
> > 
> > [ INFO: possible recursive locking detected ]
> > ---------------------------------------------
> 
> ok, lockdep should allow same-class read-lock recursion too, because 
> it's used by real code and is being relied upon. Could you try the patch 
> below? [...]

the patches are also included in the latest -mm5 combo patch at:

  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-mm5.patch

	Ingo

Re: 2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Miles Lane]

On 7/2/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Miles Lane <miles.lane@gmail.com> wrote:
> >
> > > I have patches for hostap, pcmcia and lockdep applied to this kernel.
> > > These patches are the ones resulting from several recent message
> > > threads. I just noticed this in my kernel log:
> > >
> > > [ INFO: possible recursive locking detected ]
> > > ---------------------------------------------
> >
> > ok, lockdep should allow same-class read-lock recursion too, because
> > it's used by real code and is being relied upon. Could you try the patch
> > below? [...]
>
> the patches are also included in the latest -mm5 combo patch at:
>
>   http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-mm5.patch

I have not seen this particular INFO message show up again.
Therefore, I haven't tested your latest patch yet.  I wanted to determine
whether this problem would occur often.  If you like I can go ahead and
test the patch anyhow.  I am currently testing mm5 + the pcmcia patch and
the hostap patch.  I am looking into a crashing (system lockup) bug that is
triggered by removing my Linksys USB 10/100 Ethernet adapter.  This
problem is 100% repeatable.  I am working on setting up a remote
debugging configuration.

Would you like me to go ahead and test your latest patch?

Thanks,
            Miles

Re: 2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Ingo Molnar]

* Miles Lane <miles.lane@gmail.com> wrote:

> >> ok, lockdep should allow same-class read-lock recursion too, because
> >> it's used by real code and is being relied upon. Could you try the patch
> >> below? [...]
> >
> >the patches are also included in the latest -mm5 combo patch at:
> >
> >  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-mm5.patch
> 
> I have not seen this particular INFO message show up again.

you know that the validator produces only one message per bootup, right? 
So unless you rebooted meanwhile, not seeing more messages after the 
first one is normal.

> Therefore, I haven't tested your latest patch yet.  I wanted to 
> determine whether this problem would occur often.  If you like I can 
> go ahead and test the patch anyhow.  I am currently testing mm5 + the 
> pcmcia patch and the hostap patch.  I am looking into a crashing 
> (system lockup) bug that is triggered by removing my Linksys USB 
> 10/100 Ethernet adapter.  This problem is 100% repeatable.  I am 
> working on setting up a remote debugging configuration.
> 
> Would you like me to go ahead and test your latest patch?

no hurries - just pick it up whenever you go to a new kernel.

	Ingo

Re: 2.6.17-mm4 + hostap + pcmcia + lockdep -- possible recursive locking detected -- (af_callback_keys + sk->sk_family#3){-.-?}, at: [<c119d8db>] sock_def_readable+0x15/0x69

[Miles Lane]

On 7/2/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Miles Lane <miles.lane@gmail.com> wrote:
>
> > >> ok, lockdep should allow same-class read-lock recursion too, because
> > >> it's used by real code and is being relied upon. Could you try the patch
> > >> below? [...]
> > >
> > >the patches are also included in the latest -mm5 combo patch at:
> > >
> > >  http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-mm5.patch
> >
> > I have not seen this particular INFO message show up again.
>
> you know that the validator produces only one message per bootup, right?
> So unless you rebooted meanwhile, not seeing more messages after the
> first one is normal.
>
> > Therefore, I haven't tested your latest patch yet.  I wanted to
> > determine whether this problem would occur often.  If you like I can
> > go ahead and test the patch anyhow.  I am currently testing mm5 + the
> > pcmcia patch and the hostap patch.  I am looking into a crashing
> > (system lockup) bug that is triggered by removing my Linksys USB
> > 10/100 Ethernet adapter.  This problem is 100% repeatable.  I am
> > working on setting up a remote debugging configuration.
> >
> > Would you like me to go ahead and test your latest patch?
>
> no hurries - just pick it up whenever you go to a new kernel.

Looks good here.  Thanks!

           Miles