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: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 14 Feb 2014 09:11:28 +1100
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>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Feb 13, 2014 at 11:56:36AM -0800, Christian Kujau 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.

False positive - it's confusing directory locking orders with
regular files. Already reported, but the devs responsible for the
lockdep regression have not responded. Looks like I'll have to
fix it myself. I'll see what I can do today.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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