On Sun, May 12, 2024 at 11:45:44AM -0400, James Bottomley wrote: > On Sat, 2024-05-11 at 20:28 +0100, Al Viro wrote: > > On Sat, May 11, 2024 at 11:42:34AM -0700, Linus Torvalds wrote: > > > > > so we have another level of locking going on, and my patch only > > > moved > > > the dcache pruning outside the lock of the directory we're removing > > > (not outside the lock of the directory that contains the removed > > > directory). > > > > > > 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. > > Couldn't you obviate this by doing it from a workqueue? Even if the > directory is recreated, the chances are most of the negative dentries > that were under it will still exist and be removable by the time the > workqueue runs. Eviction in general - sure shrink_dcache_parent() in particular... not really - you'd need to keep dentry pinned for that and that'd cause all kinds of fun for umount d_delete() - even worse (you don't want dcache lookups to find that sucker after rmdir(2) returned success to userland).
