On Sun, Feb 11, 2024 at 1:27 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Feb 10, 2024 at 12:06:43PM +0200, Amir Goldstein wrote: > > > I am not usually for PC culture and I know that you are on team > > "freedom of speech" ;-), but IMO this one stood out for its high ratio > > of bad taste vs. usefulness. > > > > The patch is based on your revert of "get rid of DCACHE_GENOCIDE". > > I was hoping that you could queue my patch along with the revert. > > > > BTW, why was d_genocide() only dropping refcounts on the s_root tree > > and not on the s_roots trees like shrink_dcache_for_umount()? > > Is it because dentries on s_roots are not supposed to be hashed? > > Because secondary roots make no sense for "everything's in dcache" > kind of filesystems, mostly. > > FWIW, I don't believe that cosmetic renaming is the right thing to > do here. The real issue here is that those fs-pinned dentries are > hard to distinguish. The rule is "if dentry on such filesystem is > positive and hashed, that contributes 1 to its refcount". > > Unfortunately, that doesn't come with sane locking rules. > If nothing else, I would rather have an explicit flag set along > with bumping ->d_count on creation side and cleared along with > dropping refcount on removal, both under ->d_lock. > > Another piece of ugliness is the remaining places that try to > open-code simple_recursive_removal(); they get it wrong more > often than not. Connected to the previous, since that's where > those games with simple_unlink()/simple_rmdir() and associated > fun with refcounts tend to happen. > > I'm trying to untangle that mess - on top of that revert, obviously. That sounds perfect. > Interposing your patch in there is doable, of course, > but it's not particularly useful, IMO, especially since the Merging my rename patch is not the goal. Clarifying the code is. > whole d_genocide() thing is quite likely to disappear, turning > kill_litter_super() into an alias for kill_anon_super(). 2-in-1, getting rid of cruelty in the human and animal kingdom ;) Thanks, Amir.
