Re: WARNING: at kernel/lockdep.c:690 __lock_acquire+0x168/0x164b()

[Yong Zhang <yong.zhang0@gmail.com>]

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