Messages in this thread | | | Date | Fri, 26 Aug 2011 15:18:23 -0500 | From | Shaun Ruffell <> | Subject | Re: Lockdep warning |
| |
On Fri, Aug 26, 2011 at 12:29:01PM -0500, Larry Finger wrote: > 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
It does not look like it's currently safe to call del_timer_sync in softirq context [1].
[1] http://thread.gmane.org/gmane.linux.kernel/1097241/focus=1097476
-- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org
| |