[Top] [All Lists]

Re: [BUG, 3.17-rc4] dentry still in use during unmount

To: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
Subject: Re: [BUG, 3.17-rc4] dentry still in use during unmount
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 17 Sep 2014 08:40:56 +1000
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140916223043.GY7996@xxxxxxxxxxxxxxxxxx>
References: <20140916215336.GL4322@dastard> <20140916223043.GY7996@xxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Sep 16, 2014 at 11:30:44PM +0100, Al Viro wrote:
> On Wed, Sep 17, 2014 at 07:53:36AM +1000, Dave Chinner wrote:
> > Hi Al,
> > 
> > One of my xfstest rigs tripped over this last night when running
> > xfs/301 on a pair of 4G ramdisks during an auto group run:
> > 
> > BUG: Dentry ffff8803c14fc870{i=0,n=dir}  still in use (-127) [unmount of 
> > xfs ram1]
> Umm... -127 == "already got past the beginning of __dentry_kill()".  And if
> it had been seen by d_walk() callback, it must have gotten past the point 
> where
> __dentry_kill() unlocks that sucker.
> Very interesting...  I don't see how that could happen, TBH - __dentry_kill()
> is called with parent and victim locked; it sets DCACHE_DENTRY_KILLED and
> removes the victim from parent's ->d_subdirs before dropping either lock.
> Moreover, the victim can't have any children at that point - it must have
> had the last reference held by called of __dentry_kill() and each child
> would've contributed to refcount.
> And d_walk() goes through the list of children with parent kept locked.
> It does unlock the parent after walking one level deeper, but on the
> way back it
>       * checks that there had been no renames
>       * checks that child isn't marked with DCACHE_DENTRY_KILLED
> after relocking the parent.  In case of anything fishy it restarts the
> whole thing with renames excluded.  If those tests succeed, we are guaranteed
> that we'll continue walking the parent's list of children with parent locked,
> AFAICS, not that there could legitimately be anything playing with the
> dentry tree modifications in parallel with fs shutdown...
> It might be interesting to slap WARN_ON(dentry->d_flags & 
> for dentry and target in __d_move() and for anon in __d_materialise_dentry(),
> after dentry_lock_for_move() in both functions.  And see if it triggers.
> IOW, whether it's possible for doomed dentry to be readded to someone's
> ->d_subdirs after it has entered __dentry_kill().

Ok, I'll add a debug patch to my test kernels that add these and
I'll let you know if anything triggers.


Dave Chinner

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