On Sat, May 11, 2024 at 09:31:43PM +0100, Al Viro wrote: > On Sat, May 11, 2024 at 12:55:29PM -0700, Linus Torvalds wrote: > > On Sat, 11 May 2024 at 12:28, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Sat, May 11, 2024 at 11:42:34AM -0700, Linus Torvalds wrote: > > > > > > > > And that outside lock is the much more important one, I bet. > > > > > > ... and _that_ is where taking d_delete outside of the lock might > > > take an unpleasant analysis of a lot of code. > > > > Hmm. It really shouldn't matter. There can only be negative children > > of the now deleted directory, so there are no actual effects on > > inodes. > > > > It only affects the d_child list, which is protected by d_lock (and > > can be modified outside of the inode lock anyway due to memory > > pressure). > > > > What am I missing? > > fsnotify and related fun, basically. I'll need to redo the analysis, > but IIRC there had been places where correctness had been guaranteed > by the fact that this had been serialized by the lock on parent. As an aside, I'd really love to see d_rehash() gone - the really old nest of users is gone (used to be in nfs), but there's still a weird corner case in exfat + a bunch in AFS. Life would be simpler if those had been gone - many correctness proofs around dcache have unpleasant warts dealing with that crap. Not relevant in this case, but it makes analysis harder in general...
