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

From: Dave Chinner <david@fromorbit.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [BUG, 3.17-rc4] dentry still in use during unmount
Date: Wed, 17 Sep 2014 08:40:56 +1000	[thread overview]
Message-ID: <20140916224056.GP4322@dastard> (raw)
In-Reply-To: <20140916223043.GY7996@ZenIV.linux.org.uk>

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 & DCACHE_DENTRY_KILLED)
> 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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs