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

* Thomas Gleixner <tglx@linutronix.de> wrote:

> 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 ?

i dont think it's due to code reordering. The code that lockdep flagged
is the new code in arch/i386/kernel/bootflag.c, sbf_read() and
sbf_write(). It does:

spin_lock_irqsave(&rtc_lock, flags);
CMOS_WRITE(v, sbf_port);
spin_unlock_irqrestore(&rtc_lock, flags);

and:

spin_lock_irqsave(&rtc_lock, flags);
v = CMOS_READ(sbf_port);
spin_unlock_irqrestore(&rtc_lock, flags);

and is apparently called with the xtime_lock held. Was that code ever
booted with CONFIG_PROVE_LOCKING enabled?

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/

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