2.6.17-mm3 -- BUG: trying to register non-static key!

2.6.17-mm3 -- BUG: trying to register non-static key!

[Miles Lane]

mmc0: starting CMD0 arg 00000000 flags 00000040
BUG: trying to register non-static key!
turning off the locking correctness validator.
 [<c1003502>] show_trace_log_lvl+0x54/0xfd
 [<c1003b6a>] show_trace+0xd/0x10
 [<c1003c0e>] dump_stack+0x19/0x1b
 [<c102c0a8>] __lock_acquire+0x101/0x95e
 [<c102cbca>] lock_acquire+0x60/0x80
 [<c11fcc7b>] _spin_lock_irq+0x29/0x38
 [<c11faa0a>] wait_for_completion+0x24/0xd0
 [<f8831367>] mmc_wait_for_req+0xa2/0xaf [mmc_core]
 [<f8831539>] mmc_wait_for_cmd+0x50/0x5b [mmc_core]
 [<f883162f>] mmc_idle_cards+0x83/0xe0 [mmc_core]
 [<f8831a0e>] mmc_rescan+0x18a/0xec4 [mmc_core]
 [<c1024198>] run_workqueue+0x86/0xcb
 [<c1024711>] worker_thread+0xe1/0x114
 [<c1026ca7>] kthread+0xb0/0xdc
 [<c1001005>] kernel_thread_helper+0x5/0xb
sdhci [sdhci_tasklet_finish()]: Ending request, cmd (0)

Re: 2.6.17-mm3 -- BUG: trying to register non-static key!

[Ingo Molnar]

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

> mmc0: starting CMD0 arg 00000000 flags 00000040
> BUG: trying to register non-static key!
> turning off the locking correctness validator.
> [<c1003502>] show_trace_log_lvl+0x54/0xfd
> [<c1003b6a>] show_trace+0xd/0x10
> [<c1003c0e>] dump_stack+0x19/0x1b
> [<c102c0a8>] __lock_acquire+0x101/0x95e
> [<c102cbca>] lock_acquire+0x60/0x80
> [<c11fcc7b>] _spin_lock_irq+0x29/0x38
> [<c11faa0a>] wait_for_completion+0x24/0xd0
> [<f8831367>] mmc_wait_for_req+0xa2/0xaf [mmc_core]
> [<f8831539>] mmc_wait_for_cmd+0x50/0x5b [mmc_core]
> [<f883162f>] mmc_idle_cards+0x83/0xe0 [mmc_core]
> [<f8831a0e>] mmc_rescan+0x18a/0xec4 [mmc_core]
> [<c1024198>] run_workqueue+0x86/0xcb
> [<c1024711>] worker_thread+0xe1/0x114
> [<c1026ca7>] kthread+0xb0/0xdc
> [<c1001005>] kernel_thread_helper+0x5/0xb
> sdhci [sdhci_tasklet_finish()]: Ending request, cmd (0)

does the patch below fix this?

	Ingo

------->
Subject: lockdep: annotate on-stack completions, mmc
From: Ingo Molnar <mingo@elte.hu>

lockdep needs to have the waitqueue lock initialized for on-stack
waitqueues implicitly initialized by DECLARE_COMPLETION().

Annotate mmc_wait_for_req()'s on-stack completion accordingly.

Has no effect on non-lockdep kernels.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/mmc/mmc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/drivers/mmc/mmc.c
===================================================================
--- linux.orig/drivers/mmc/mmc.c
+++ linux/drivers/mmc/mmc.c
@@ -129,7 +129,7 @@ static void mmc_wait_done(struct mmc_req
 
 int mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq)
 {
-	DECLARE_COMPLETION(complete);
+	DECLARE_COMPLETION_ONSTACK(complete);
 
 	mrq->done_data = &complete;
 	mrq->done = mmc_wait_done;

Re: 2.6.17-mm3 -- BUG: trying to register non-static key!

[Miles Lane]

After rebuilding with your patch, the stack trace shows up,
but now there is a warning of a possible circular locking dependency:

[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
S13gdm/2088 is trying to acquire lock:
 (&dev->queue_lock){-+..}, at: [<c11a1fbc>] dev_queue_xmit+0x120/0x248

but task is already holding lock:
 (&dev->_xmit_lock){-+..}, at: [<c11a201f>] dev_queue_xmit+0x183/0x248

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&dev->_xmit_lock){-+..}:
       [<c102cbca>] lock_acquire+0x60/0x80
       [<c11fcafd>] _spin_lock_bh+0x28/0x37
       [<c11acd1e>] dev_activate+0xce/0x100
       [<c11a844b>] linkwatch_run_queue+0x10b/0x138
       [<c11a849c>] linkwatch_event+0x24/0x2b
       [<c1024198>] run_workqueue+0x86/0xcb
       [<c1024711>] worker_thread+0xe1/0x114
       [<c1026ca7>] kthread+0xb0/0xdc
       [<c1001005>] kernel_thread_helper+0x5/0xb

-> #0 (&dev->queue_lock){-+..}:
       [<c102cbca>] lock_acquire+0x60/0x80
       [<c11fcac6>] _spin_lock+0x23/0x32
       [<c11a1fbc>] dev_queue_xmit+0x120/0x248
       [<f886779e>] hostap_data_start_xmit+0x610/0x61a [hostap]
       [<c11a0641>] dev_hard_start_xmit+0x206/0x212
       [<c11a203b>] dev_queue_xmit+0x19f/0x248
       [<f8c48cb3>] mld_sendpack+0x1a0/0x24d [ipv6]
       [<f8c4984c>] mld_ifc_timer_expire+0x1b2/0x1d9 [ipv6]
       [<c101d8da>] run_timer_softirq+0xf2/0x14a
       [<c101a4aa>] __do_softirq+0x55/0xb0
       [<c1004a64>] do_softirq+0x58/0xbd

other info that might help us debug this:

1 lock held by S13gdm/2088:
 #0:  (&dev->_xmit_lock){-+..}, at: [<c11a201f>] dev_queue_xmit+0x183/0x248

stack backtrace:
 [<c1003502>] show_trace_log_lvl+0x54/0xfd
 [<c1003b6a>] show_trace+0xd/0x10
 [<c1003c0e>] dump_stack+0x19/0x1b
 [<c102bf9c>] print_circular_bug_tail+0x59/0x64
 [<c102c770>] __lock_acquire+0x7c9/0x95e
 [<c102cbca>] lock_acquire+0x60/0x80
 [<c11fcac6>] _spin_lock+0x23/0x32
 [<c11a1fbc>] dev_queue_xmit+0x120/0x248
 [<f886779e>] hostap_data_start_xmit+0x610/0x61a [hostap]
 [<c11a0641>] dev_hard_start_xmit+0x206/0x212
 [<c11a203b>] dev_queue_xmit+0x19f/0x248
 [<f8c48cb3>] mld_sendpack+0x1a0/0x24d [ipv6]
 [<f8c4984c>] mld_ifc_timer_expire+0x1b2/0x1d9 [ipv6]
 [<c101d8da>] run_timer_softirq+0xf2/0x14a
 [<c101a4aa>] __do_softirq+0x55/0xb0
 [<c1004a64>] do_softirq+0x58/0xbd
 [<c101a544>] irq_exit+0x3f/0x4b
 [<c1004b69>] do_IRQ+0xa0/0xaf
 [<c1002fd9>] common_interrupt+0x25/0x2c
[drm] Initialized drm 1.0.1 20051102

Re: 2.6.17-mm3 -- BUG: trying to register non-static key!

[Arjan van de Ven]

On Wed, 2006-06-28 at 11:09 -0700, Miles Lane wrote:
> After rebuilding with your patch, the stack trace shows up,
> but now there is a warning of a possible circular locking dependency:
> 
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> S13gdm/2088 is trying to acquire lock:
>  (&dev->queue_lock){-+..}, at: [<c11a1fbc>] dev_queue_xmit+0x120/0x248
> 
> but task is already holding lock:
>  (&dev->_xmit_lock){-+..}, at: [<c11a201f>] dev_queue_xmit+0x183/0x248
> 
> which lock already depends on the new lock.
> 

ok this driver calls dev_queue_xmit() inside a ->hard_start_xmit
handler... that smells fishy.

Jeff/DaveM: is that legal ?