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.
