Re: [RFC] freeing unlinked file indefinitely delayed

[Al Viro]

On Thu, Jul 09, 2015 at 07:26:44PM +0800, Ian Kent wrote:
> > But the dentrys that will most likely face summary execution will be
> > hashed, such as was the case on that 2.6.32 kernel at dput().
> > 
> > Doesn't that mean that something dropped the dentry after the dput(),
> > that will now also free the dentry, that took the refcount to 0?
> 
> Oh wait, think I get it now ... perhaps it's prune_one_dentry() doing
> it ...

What, unhashing?  Yes, it does.

A bit of context - the breakage that had first pointed in direction of
this bug had been a deadlock with dcache shrinker run on frozen fs was
stumbling across a hashed dentry with zero refcount *and* zero link count
of its inode, triggering its eviction, final iput(), inode freeing and
deadlock on attempt to do sb_start_intwrite() there; figuring out how could
such a dentry appear in the first place had uncovered this fun.  Which
	a) is a bug in its own right and
	b) happens in mainline as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/