Re: Fwd: 2.6.17-rc5-mm1

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/