On Sat, Aug 01, 2015 at 09:06:55PM -0700, Hugh Dickins wrote: > (I don't actually understand why the clearing of DCACHE_ENTRY_TYPE in > dentry_iput() is not of continuing concern; but don't worry, there's > plenty I don't understand - so long as you're both satisfied that > it's not a concern, no need to persuade me.) Because before we even get to dentry_iput(), we evict the fucker from hash. And that will do dentry_rcuwalk_invalidate(dentry), which will bump ->d_seq *AFTER* having it unhashed. Now look at __d_lookup_rcu() - there we fetch ->d_seq, then verify that it's still hashed. So having hit dentry_iput() means that everyone who'd found it via RCU lookup will be guaranteed a ->d_seq mismatch. The same goes for things like d_drop() and d_instantiate(). Look for dentry_rcuwalk_invalidate() callers in there... Clearing DCACHE_ENTRY_TYPE there is fine - dentry *is* made negative there, after all. What we want is to have ->d_inode stable at least as long as ->d_seq remains so. -- 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
