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@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
