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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
