lkml.org 
[lkml]   [2007]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: LOCKDEP: possible irq lock inversion dependency detected
From
Date
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/

\
 
 \ /
  Last update: 2007-05-23 06:09    [W:0.380 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site