* Michal Piotrowski <[email protected]> wrote:
> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {in-hardirq-W} -> {hardirq-on-W} usage.
sorry - the messages are indeed cryptic, partly because there are lots
of illegal state transitions and the printout is atomated, and partly to
keep the already sizable lockdep printouts as compact as possible.
What happened here is that a lock (-type) that had the {in-hardirq-W}
state bit set, and lockdep observed an event that also sets the
{hardirq-on-W} state bit: illegal.
here is a rough translation of the usage history state bits:
{in-hardirq-W}: lock was exclusively acquired in hardirq context
{in-hardirq-R}: lock was read-acquired in hardirq context
{in-softirq-W}: lock was exclusively acquired in softirq context
{in-softirq-R}: lock was read-acquired in softirq context
{hardirq-on-W}: lock was held exclusively with hardirqs enabled
{hardirq-on-R}: lock was read-held with hardirqs enabled
{softirq-on-W}: lock was held exclusively with softirqs enabled
{softirq-on-R}: lock was read-held with softirqs enabled
to interpret the lock state at a glance, there's an even shorter
representation of the state bits:
(&base->lock#2){++..}
^^^^
'+' : irq-safe [lock was taken in irq context]
'-' : irq-unsafe [lock was taken with irqs enabled]
'.' : unknown [lock has not yet become irq-safe or irq-unsafe]
'?' : read-locked with both hardirq context and with irqs enabled
the first character is for exclusive-locking in hardirqs, the second for
exclusive-locking in softirqs, the third is for read-locking in
hardirqs, the fourth is for read-locking in softirqs.
this means that the "{++..}" sequence shows that this lock is
hardirq-safe and softirq-safe, and was never read-locked. [the later one
is not surprising from a spinlock - but lockdep doesnt know that it's a
spinlock, it deals with all lock types in a unified way]
(more details about the usage history state bits are in
Documentation/lockdep-design.txt and in include/linux/lockdep.h)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
