Re: [RFC] dentry->d_flags locking

[Christian Brauner <brauner@kernel.org>]

On Mon, Feb 24, 2025 at 01:38:44AM +0000, Al Viro wrote:
> 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?

No, I don't think so. I put patches on top of vfs.fixes that remove it
for both pidfs and nsfs. Thanks!

The fact that hashing a dentry happens during lookup and that I didn't
even have to think about lookup for pidfs and nsfs because they don't
matter probably just led to carrying this over for pidfs.

I think it would be worthwhile to mark dentries of such filesystems as
always unhashed and then add an assert into fs/dcache.c whenever such a
dentry should suddenly become hashed.

That would not just make it very easy to see for the reviewer that the
dentries of this filesystem are always unhashed it would also make it
possible to spot bugs.