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: Windows password security audit tool. GUI, reports in PDF.

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

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

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