[RFC][PATCHES v2] dentry->d_flags locking

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Feb 24, 2025 at 12:45:49PM +0100, Christian Brauner wrote:

> Also mentioned in my other reply: Can you please make the unhashed case
> really explicit ideally at dentry allocation time. IOW, that there's a
> flag or some other way of simply identifying a dentry as belonging to an
> fs that will never hash them?

This really doesn't make sense; on all those filesystems we *do* want
everything positive to be hashed.  So I don't see anything useful that
fs/dcache.c could check, not to mention how much I dislike behaviour
that depends upon "feature flags" in file_system_type in general.

All dentries are allocated unhashed negative; a plenty of such fs
go through the normal lookup helpers when they populate their
trees.  Sure, we could have their ->lookup() just return NULL
and be done with that, but then we'd have to modify the code
that handles attaching the damn things to inodes accordingly...

I don't see any point, especially since it would just create churn
for tree-in-dcache series porting^Wresurrection, which I'm going
to do this weekend.

Or are you talking about DCACHE_DONTCACHE (i.e. "unhash as soon as
refcount hits 0", rather than "never hash it at all")?

Anyway, I have ported the "safe ->d_flags" series (this thread) to
6.16-rc1.  Changes:

* several commits got dropped (merged or, as in afs dynroot case, invalidated)
* procfs flag moved to include/linux/procfs.h, deconflicted.
* tracefs told to set DCACHE_DONTCACHE on everything; it is a behaviour
change, and IMO the correct one.
* in "simple_lookup(): just set DCACHE_DONTCACHE", don't set the flag if
->d_op had been set and DCACHE_DONTCACHE wasn't already present.  That
matches the mainline logics.  See comments in that commit...

Force-pushed into
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache
Individual patches in followups; if nobody comes up with objections,
into #for-next it goes.  Folks, please review.