3.14-rc2: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected
Chris Murphy
lists at colorremedies.com
Thu Feb 13 14:42:11 CST 2014
On Feb 13, 2014, at 12:56 PM, Christian Kujau <lists at nerdbynature.de> 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
More information about the xfs
mailing list