linux-kernel - Re: LOCKDEP: possible irq lock inversion dependency detected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 23 May 2007 08:20:23 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	LKML <Linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: LOCKDEP: possible irq lock inversion dependency detected


* Thomas Gleixner <tglx@...utronix.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/