xfs
[Top] [All Lists]

Re: 3.14-rc2: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected

To: Christian Kujau <lists@xxxxxxxxxxxxxxx>
Subject: Re: 3.14-rc2: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected
From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
Date: Thu, 13 Feb 2014 13:42:11 -0700
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.19.4.1402131153300.6233@xxxxxxxxxxxxxx>
References: <alpine.DEB.2.19.4.1402120008320.6233@xxxxxxxxxxxxxx> <alpine.DEB.2.19.4.1402131153300.6233@xxxxxxxxxxxxxx>
On Feb 13, 2014, at 12:56 PM, Christian Kujau <lists@xxxxxxxxxxxxxxx> wrote:

> On Wed, 12 Feb 2014 at 00:11, Christian Kujau wrote:
>> After upgrading from 3.13-rc8 to 3.14-rc2 on this PowerPC G4 machine, this 
>> happened:
> 
> Yesterday a slighly different lockdep warning was printed:
> 
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 3.14.0-rc2 #1 Tainted: G        W   
> ---------------------------------------------------------
> kswapd0/279 just changed the state of lock:
>  (&(&ip->i_lock)->mr_lock){++++.?}, at: [<c01c213c>] 
> xfs_free_eofblocks+0xe8/0x2e0
> but this lock took another, RECLAIM_FS-unsafe lock in the past:
>  (&mm->mmap_sem){++++++}
> 
> and interrupts could create inverse lock ordering between them.
> 
> 
> other info that might help us debug this:
>  Possible interrupt unsafe locking scenario:
> 
>        CPU0                    CPU1
>        ----                    ----
>   lock(&mm->mmap_sem);
>                                local_irq_disable();
>                                lock(&(&ip->i_lock)->mr_lock);
>                                lock(&mm->mmap_sem);
>   <Interrupt>
>     lock(&(&ip->i_lock)->mr_lock);
> 
>  *** DEADLOCK ***
> 
> 2 locks held by kswapd0/279:
>  #0:  (shrinker_rwsem){++++..}, at: [<c00a5218>] shrink_slab+0x40/0x13c
>  #1:  (&type->s_umount_key#36){+++++.}, at: [<c00d4840>] 
> grab_super_passive+0x54/0xc0
> the shortest dependencies between 2nd lock and 1st lock:
>  -> (&mm->mmap_sem){++++++} ops: 58148911 {
>     HARDIRQ-ON-W at:
>                       [<c0066b38>] lock_acquire+0x4c/0x68
>                       [<c0558724>] down_write+0x4c/0x98
>                       [<c00d88fc>] do_execve+0x2dc/0x574
>                       [<c000425c>] try_to_run_init_process+0x18/0x58
>                       [<c0004a48>] kernel_init+0xac/0x104
>                       [<c0010ae4>] ret_from_kernel_thread+0x5c/0x64
> 
> 
> …and on it goes, full dmesg: http://nerdbynature.de/bits/3.14-rc2/mm/

A user is seeing something similar on Fedora 3.14.x kernels with Btrfs also.


https://bugzilla.redhat.com/show_bug.cgi?id=1062439



Chris Murphy


<Prev in Thread] Current Thread [Next in Thread>