Messages in this thread | | | Date | Tue, 30 May 2006 21:59:02 +0200 | From | Ingo Molnar <> | Subject | Re: Fwd: 2.6.17-rc5-mm1 |
| |
* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |