What does inconsistent lock state mean?

[Srivatsa Bhat]

On Thu, Dec 8, 2011 at 4:49 AM, Kai Meyer <kai at gnukai.com> wrote:

> I'm getting this when I try to spin_unlock a recently acquired lock with
> spin_lock. IRQs are still somewhat of a mystery to me, and cryptic lock
> state symbols (IN-HARDIRQ-W, HARDIRQ-ON-W) are unintelligible to me.
>
> Dec  7 15:52:20 dev2 kernel: =================================
> Dec  7 15:52:20 dev2 kernel: [ INFO: inconsistent lock state ]
> Dec  7 15:52:20 dev2 kernel: 2.6.32-220.el6.x86_64.debug #1
> Dec  7 15:52:20 dev2 kernel: ---------------------------------
> Dec  7 15:52:20 dev2 kernel: inconsistent {IN-HARDIRQ-W} ->
> {HARDIRQ-ON-W} usage.
>
> Looking at lockdep.c isn't giving me any help either. It's obfuscated
> beyond my ability to grok by simply reading the code.
>
> It seems like this portion should help me, but it doesn't....
> Dec  7 15:52:20 dev2 kernel: {IN-HARDIRQ-W} state was registered at:
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff810afbca>]
> __lock_acquire+0x77a/0x1570
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff810b0a64>] lock_acquire+0xa4/0x120
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff81520c75>]
> _spin_lock_irqsave+0x55/0xa0
> Dec  7 15:52:20 dev2 kernel:  [<ffffffffa006b19b>] blk_done+0x2b/0x110
> [virtio_blk]
> Dec  7 15:52:20 dev2 kernel:  [<ffffffffa00401dc>]
> vring_interrupt+0x3c/0xd0 [virtio_ring]
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff810ec080>]
> handle_IRQ_event+0x50/0x160
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff810ee840>]
> handle_edge_irq+0xe0/0x170
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff8100e059>] handle_irq+0x49/0xa0
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff81526cdc>] do_IRQ+0x6c/0xf0
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff8100ba93>] ret_from_intr+0x0/0x16
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff810148e2>] default_idle+0x52/0xc0
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff81009e0b>] cpu_idle+0xbb/0x110
> Dec  7 15:52:20 dev2 kernel:  [<ffffffff81516623>]
> start_secondary+0x211/0x254
>
> Then later it tells me that I'm holding 1 lock, which is the one that I
> mentioned at the beginning that was just recently locked.
>
>
2 things:
1. Documentation/lockdep-design.txt explains the "cryptic lock state
symbols".
2. Please post the lockdep splat _exactly_ as it appears, and _in full_
    (and without line-wrapping, if possible). Usually lockdep is intelligent
    enough to tell you the possible scenario that would lock up your system.
    That gives a very good clue, in case you find it difficult to make out
what
     is wrong from the cryptic symbols.

Regards,
Srivatsa S. Bhat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111208/808a522b/attachment.html