On Sat, 03 Sep 2022, Al Viro wrote: > On Mon, Aug 29, 2022 at 11:59:02AM +1000, NeilBrown wrote: > > > > When would we get out of __lookup_hash() with in-lookup dentry? > > > Confused... > > > > Whenever wq is passed in and ->lookup() decides, based on the flags, to do > > nothing. > > NFS does this for LOOKUP_CREATE|LOOKUP_EXCL and for LOOKUP_RENAME_TARGET > > Frankly, I would rather do what all other callers of ->lookup() do and > just follow it with d_lookup_done(dentry), no matter what it returns. > It's cheap enough... > I don't think that is a good idea. Once you call d_lookup_done() (without having first called d_add() or similar) the dentry becomes invisible to normal path lookup, so another might be created. But the dentry will still be used for the 'create' or 'rename' and may then be added to the dcache - at which point you could have two dentries with the same name. When ->lookup() returns success without d_add()ing the dentry, that means that something else will complete the d_add() if/when necessary. For NFS, it specifically means that the lookup is effectively being combined with the following CREATE or RENAME. In this case there is no d_lookup_done() until the full operation is complete. For autofs (thanks for pointing me to that) the operation is completed when d_automount() signals the daemon to create the directory or symlink. In that case there IS a d_lookup_done() call and autofs needs some extra magic (the internal 'active' list) to make sure subsequent ->lookup requests can see that dentry which is still in the process of being set up. It might be nice if the dentry passed to autofs_lookup() could remain "d_inlookup()" until after d_automount has completed. Then autofs wouldn't need that active list. However I haven't yet looked at how disruptive such a change might be. Thanks, NeilBrown