lkml.org 
[lkml]   [2011]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: WARNING: at kernel/lockdep.c:690 __lock_acquire+0x168/0x164b()
On Fri, Nov 04, 2011 at 12:31:24PM +0300, Sergey Senozhatsky wrote:
> On (11/04/11 10:25), Borislav Petkov wrote:
> > > Understood. If someone can come up with a simple patch which could
> > > cover the case I mentioned before, that would be great.
> > > /me goes to poke at it.
> >
> > I dunno whether this is related but I get the following on 3.1:
> >
>
> I think this is different problem. Failed check that lockdep key is marked as `static'.

Actually the lockdep_init_map() in __lock_set_class could lead to
more problem, such as: certain rq->lock could have different 'key'
with what we give them in sched_init() because rq is defined staticly.

Given that, we could have another typical race:

CPU A CPU B
lock_set_subclass(lockA);
lock_set_class(lockA);
/* lockA->class_cache[] is not set */
register_lock_class(lockA);
look_up_lock_class(lockA); /* retrun NULL */
lockdep_init_map(lockA);
/* lockA->name is cleared */
memset(lockA);
if (!static_obj(lock->key))
/* we get warning here */
lock->name = name;


So memset() in lockdep_init_map() is still the culprit IMHO.

Thanks,
Yong

>
> Sergey
>
> > [ 5499.537074] INFO: trying to register non-static key.
> > [ 5499.537080] the code is fine but needs lockdep annotation.
> > [ 5499.537083] turning off the locking correctness validator.
> > [ 5499.537088] Pid: 0, comm: kworker/0:1 Not tainted 3.1.0 #1
> > [ 5499.537091] Call Trace:
> > [ 5499.537094] <IRQ> [<ffffffff8107beed>] __lock_acquire+0x165d/0x1e30
> > [ 5499.537109] [<ffffffff810321fc>] ? double_rq_lock+0x2c/0x80
> > [ 5499.537115] [<ffffffff8107ccd3>] lock_acquire+0x93/0x160
> > [ 5499.537120] [<ffffffff810321fc>] ? double_rq_lock+0x2c/0x80
> > [ 5499.537126] [<ffffffff814d9866>] _raw_spin_lock+0x36/0x50
> > [ 5499.537130] [<ffffffff810321fc>] ? double_rq_lock+0x2c/0x80
> > [ 5499.537135] [<ffffffff810321fc>] double_rq_lock+0x2c/0x80
> > [ 5499.537140] [<ffffffff81039195>] load_balance+0x215/0x6c0
> > [ 5499.537146] [<ffffffff81039640>] ? load_balance+0x6c0/0x6c0
> > [ 5499.537151] [<ffffffff810396fd>] rebalance_domains+0xbd/0x1d0
> > [ 5499.537155] [<ffffffff81039640>] ? load_balance+0x6c0/0x6c0
> > [ 5499.537161] [<ffffffff810398ec>] run_rebalance_domains+0xdc/0x130
> > [ 5499.537166] [<ffffffff81048dcd>] __do_softirq+0xbd/0x290
> > [ 5499.537173] [<ffffffff814dc42c>] call_softirq+0x1c/0x30
> > [ 5499.537178] [<ffffffff81003eb5>] do_softirq+0x85/0xc0
> > [ 5499.537183] [<ffffffff810492ce>] irq_exit+0x9e/0xc0
> > [ 5499.537189] [<ffffffff8101ca9f>] smp_call_function_single_interrupt+0x2f/0x40
> > [ 5499.537195] [<ffffffff814dbeb0>] call_function_single_interrupt+0x70/0x80
> > [ 5499.537199] <EOI> [<ffffffff810096e6>] ? native_sched_clock+0x26/0x70
> > [ 5499.537212] [<ffffffffa0038e1a>] ? acpi_idle_enter_simple+0xee/0x11f [processor]
> > [ 5499.537221] [<ffffffffa0038e15>] ? acpi_idle_enter_simple+0xe9/0x11f [processor]
> > [ 5499.537227] [<ffffffff813f8b1d>] cpuidle_idle_call+0xdd/0x350
> > [ 5499.537233] [<ffffffff8100081f>] cpu_idle+0x6f/0xd0
> > [ 5499.537238] [<ffffffff814cc665>] start_secondary+0x1ae/0x1b3
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
Only stand for myself


\
 
 \ /
  Last update: 2011-11-07 05:57    [W:0.189 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site