Re: [PATCH 08/11] VFS: allow d_splice_alias() and d_add() to work on hashed dentries.

NeilBrown <[email protected]>
Newsgroups org.kernel.vger.ecryptfs,dev.linux.lists.netfs,org.infradead.lists.linux-um,org.kernel.vger.ceph-devel,org.kernel.vger.linux-cifs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs
Message-ID <[email protected]>
On Thu, 26 Feb 2026, NeilBrown wrote:
> 
> d_add_hashed() would be much the same as d_instantiate(), and that
> could be used for d_splice_alias() when the dentry is hashed.
> There aren't any cases where d_splice_alias() is called with a directory
> inode and a hashed dentry.

There are of course... mkdir() is given a hashed negative dentry and may
need to use d_splice_alias() if there is any chance the inode was
accessible (e.g. by fhandle) before the splice can happen.

Maybe we could always give mkdir a d_in_lookup() alias?

As it is, generic "create object" code inside a filesystem may need to
handle three cases:

 d_in_lookup() - use d_splice_alias()
 otherwise if non-dir: - use d_instantiate
 otherwise - use some new d_add_or_obtain (name taken from NFS) which 
     does the right thing with directories.

Currently most d_drop() and use d_splice_alias() but I need to avoid the
d_drop().

Thanks,
NeilBrown
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.