Re: [RFC] dentry->d_flags locking

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

On Mon, Feb 24, 2025 at 01:06:24AM +0000, Al Viro wrote:

> PS: turns out that set_default_d_op() is slightly more interesting
> than I expected - fuse has separate dentry_operations for its
> root dentry.  I don't see the point, TBH - the only difference is
> that root one lacks
> 	* ->d_delete() (never even called for root dentry; it's
> only called if d_unhashed() is false)
> 	* ->d_revalidate() (never called for root)
> 	* ->d_automount() (not even looked at unless you have
> S_AUTOMOUNT set on the inode).
> What's wrong with using fuse_dentry_operations for root dentry?
> Am I missing something subtle here?  Miklos?

Speaking of fun questions - does pidfs_dentry_operations need
->d_delete()?  I mean, it's not even called for unhashed
dentries and AFAICS there's no way for those to be hashed...
The same goes for all filesystems created by init_pseudo().

Is there any reason to have that in pidfs_dentry_operations and
ns_dentry_operations?

I think nsfs is my sloppiness back then - original commit message
explicitly says that neither dentries nor inodes in that thing
are ever hashed, so ->d_delete() had been clearly pointless
from the very beginning.

Christian, pidfs looks like it just had copied that from nsfs.
Is there something subtle about pidfs that makes ->d_delete()
needed there?