[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E57D7DD.5030902@lwfinger.net>
Date: Fri, 26 Aug 2011 12:29:01 -0500
From: Larry Finger <Larry.Finger@...inger.net>
To: LKML <linux-kernel@...r.kernel.org>
Subject: Lockdep warning
With a new version of the staging driver rtl8192e, I'm getting the lockdep
warning posted below. The lock in question is for a timer that uses init_timer()
for initialization. From the definition of that macro, I thought this was
initialized with a lock_class_key that should prevent this warning. Obviously,
I'm missing something.
Any pointers would be appreciated.
Thanks,
Larry
[ 88.048077] =============================================
[ 88.048086] [ INFO: possible recursive locking detected ]
[ 88.048093] 3.1.0-rc3-staging+ #5
[ 88.048097] ---------------------------------------------
[ 88.048102] kmemleak/631 is trying to acquire lock:
[ 88.048108] (ptimer){+.-...}, at: [<ffffffff81059370>] del_timer_sync+0x0/0xc0
[ 88.048124]
[ 88.048125] but task is already holding lock:
[ 88.048131] (ptimer){+.-...}, at: [<ffffffff81058e54>]
run_timer_softirq+0x124/0x400
[ 88.048142]
[ 88.048143] other info that might help us debug this:
[ 88.048149] Possible unsafe locking scenario:
[ 88.048150]
[ 88.048156] CPU0
[ 88.048159] ----
[ 88.048162] lock(ptimer);
[ 88.048167] lock(ptimer);
[ 88.048172]
[ 88.048173] *** DEADLOCK ***
[ 88.048174]
[ 88.048179] May be due to missing lock nesting notation
[ 88.048180]
[ 88.048187] 2 locks held by kmemleak/631:
[ 88.048191] #0: (scan_mutex){+.+...}, at: [<ffffffff81122e76>]
kmemleak_scan_thread+0x56/0xd0
[ 88.048206] #1: (ptimer){+.-...}, at: [<ffffffff81058e54>]
run_timer_softirq+0x124/0x400
[ 88.048218]
[ 88.048219] stack backtrace:
[ 88.048225] Pid: 631, comm: kmemleak Tainted: G C 3.1.0-rc3-staging+ #5
[ 88.048232] Call Trace:
[ 88.048236] <IRQ> [<ffffffff81083cbb>] __lock_acquire+0x119b/0x1ea0
[ 88.048254] [<ffffffff81084fa5>] lock_acquire+0x95/0x120
[ 88.048263] [<ffffffff81059370>] ? process_timeout+0x10/0x10
[ 88.048272] [<ffffffff810593ac>] del_timer_sync+0x3c/0xc0
[ 88.048280] [<ffffffff81059370>] ? process_timeout+0x10/0x10
[ 88.048289] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
[ 88.048316] [<ffffffffa008d1ee>] TsInitAddBA+0x6e/0x170 [r8192e_pci]
[ 88.048332] [<ffffffffa008b4b3>] TsAddBaProcess+0x33/0x50 [r8192e_pci]
[ 88.048341] [<ffffffff81058edb>] run_timer_softirq+0x1ab/0x400
[ 88.048350] [<ffffffff81058e54>] ? run_timer_softirq+0x124/0x400
[ 88.048364] [<ffffffffa008b480>] ? RxPktPendingTimeout+0x2d0/0x2d0 [r8192e_pci]
[ 88.048377] [<ffffffff810502ad>] __do_softirq+0xbd/0x210
[ 88.048386] [<ffffffff810714d7>] ? hrtimer_interrupt+0x137/0x240
[ 88.048396] [<ffffffff8137176c>] call_softirq+0x1c/0x30
[ 88.048406] [<ffffffff810048c5>] do_softirq+0x85/0xc0
[ 88.048414] [<ffffffff81050686>] irq_exit+0x96/0xc0
[ 88.048422] [<ffffffff8101e4e9>] smp_apic_timer_interrupt+0x69/0xa0
[ 88.048431] [<ffffffff8136fff0>] apic_timer_interrupt+0x70/0x80
[ 88.048438] <EOI> [<ffffffff8136ea4d>] ? _raw_spin_unlock_irqrestore+0x3d/0x70
[ 88.048452] [<ffffffff81122315>] scan_gray_list+0x155/0x170
[ 88.048460] [<ffffffff8112262b>] kmemleak_scan+0x2fb/0x6e0
[ 88.048468] [<ffffffff81122330>] ? scan_gray_list+0x170/0x170
[ 88.048477] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048485] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048494] [<ffffffff81122e7b>] kmemleak_scan_thread+0x5b/0xd0
[ 88.048502] [<ffffffff81122e20>] ? kmemleak_write+0x390/0x390
[ 88.048510] [<ffffffff8106c8e6>] kthread+0x96/0xa0
[ 88.048519] [<ffffffff81371674>] kernel_thread_helper+0x4/0x10
[ 88.048527] [<ffffffff8136ed9d>] ? retint_restore_args+0xe/0xe
[ 88.048536] [<ffffffff8106c850>] ? __init_kthread_worker+0x70/0x70
[ 88.048544] [<ffffffff81371670>] ? gs_change+0xb/0xb
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists