"inconsistent lock state"

Arvid Brodin arvid.brodin at enea.com
Thu Jan 27 14:15:24 EST 2011


I'm using spinlocks (spin_lock_irqsave() / spin_unlock_irqrestore()) to 
protect shared resources between softirq, hardirq and non-irq kernel 
contexts. When I configure PROVE_LOCKING I get

[ INFO: inconsistent lock state ] #148
inconsistent {softirq-on-W} -> {in-softirq-W} usage.
khubd/85 [HC0[0]:SC1[1]:HE0:SE0] takes:
  (&priv->lock){-+..}, at: [<90152430>] schedule_ptds+0x54/0x564
{softirq-on-W} state was registered at:
   [<9003856e>] trace_hardirqs_on_caller+0x92/0xc4
   [<900385a8>] trace_hardirqs_on+0x8/0xc
   [<90058fc2>] __slab_alloc+0xee/0x3e4
   [<90059f9c>] kmem_cache_alloc+0x30/0x70


I don't understand why. Assuming that "{softirq-on-W} -> {in-softirq-W}" 
means that the problem is that the lock was taken in "softirq on" (irqs 
enabled) state, and at some later time in softirq context, then what is 
the problem? spin_lock_irqsave() disables irqs, right? So after the lock 
is taken in non-irq context, softirq cannot interrupt?

There are code paths like this:


in both non-irq and softirq contexts. Could this be a problem? If I 
understand correctly, spin_lock() and spin_unlock() does not touch irq 
settings, so the usage above should be fine, right?

Arvid Brodin
Enea Services Stockholm AB

More information about the Kernelnewbies mailing list