Messages in this thread | | | Subject | Re: LOCKDEP: possible irq lock inversion dependency detected | From | Thomas Gleixner <> | Date | Wed, 23 May 2007 06:06:20 +0200 |
| |
On Tue, 2007-05-22 at 17:19 -0700, Sven-Thorsten Dietrich wrote: > swapper/1 just changed the state of lock: > (rtc_lock#2){-...}, at: [<ffffffff8085b185>] sbf_init+0x25/0xe0 > but this lock was taken by another, hard-irq-safe lock in the past: > (xtime_lock){+...} > > and interrupts could create inverse lock ordering between them. > > > other info that might help us debug this: > no locks held by swapper/1. > > the first lock's dependencies: > -> (rtc_lock#2){-...} ops: 2 { > initial-use at: > [<ffffffff8025d383>] mark_lock+0xf3/0x5b0 > [<ffffffff8025e6f4>] __lock_acquire+0x664/0xf80 > [<ffffffff8025f098>] lock_acquire+0x88/0xc0 > [<ffffffff8047e2c5>] rt_spin_lock+0x35/0x40 > [<ffffffff8020e162>] read_persistent_clock+0x22/0x1b0 > [<ffffffff80867e86>] timekeeping_init+0x86/0x100 > [<ffffffff808537af>] start_kernel+0x1bf/0x350 > [<ffffffff80853179>] _sinittext+0x179/0x180 > [<ffffffffffffffff>] 0xffffffffffffffff
Hmm. That's the code in question:
void __init timekeeping_init(void) { unsigned long flags; unsigned long sec = read_persistent_clock(); write_seqlock_irqsave(&xtime_lock, flags);
The rtc_lock is never taken inside the xtime_lock.
Looks like code reordering due to gcc extra magic. Which compiler ?
Thanks,
tglx
- 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/
| |