On Sun, 2015-07-12 at 16:17 +0100, Al Viro wrote: > 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. Yep, that was what I was thinking at the time. > > 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. I get all of that, and it sure does look like these things should be treated as unhashed. My puzzle is the life cycle of DCACHE_DISCONNECTED dentrys, which is mostly unrelated. Not to worry, this isn't the first time I've been defeated trying to work it out. The only way I can see disconnected dentrys created (possibly unhashed, and maybe not materialized) is via nfs and nfsd, beside the usage mentioned here of course. There must be some indirection I'm missing wrt. export_operations usage .... Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
