On Sun, May 12, 2024 at 12:59:57PM -0700, Linus Torvalds wrote: > so the removed directory entry itself will have either turned into a > negatve dentry or will unhash it (if there are other users). > > So the children are already unreachable through that name, and can > only be reached through somebody who still has the directory open. And > I do not see how "rmdir()" can *possibly* have any valid semantic > effect on any user that has that directory as its PWD, so I claim that > the dentries that exist at this point must already not be relevant > from a semantic standpoint. > > So Al, this is my argument: the only dentry that *matters* is the > dentry of the removed directory itself, and that's the one that sees > the "d_delete()" (and all the noise to make sure you can't do new > lookups and can't mount on top of it). Recall what d_delete() will do if you have other references. That's why we want shrink_dcache_parent() *before* d_delete(). BTW, example of the reasons why d_delete() without directory being locked is painful: simple_positive() is currently called either under ->d_lock on dentry in question or under ->i_rwsem on the parent. Either is enough to stabilize it. Get d_delete() happening without parent locked and all callers of simple_positive() must take ->d_lock. This one is not hard to adjust, but we need to find all such places. Currently positivity of hashed dentry can change only with parent held exclusive. It's going to take some digging...
