On Wed, 13 Aug 2025, Al Viro wrote: > On Tue, Aug 12, 2025 at 12:25:13PM +1000, NeilBrown wrote: > > > + * If it is d_in_lookup() then these conditions can only be checked by the > > + * file system when carrying out the intent (create or rename). > > I do not understand. In which cases would that happen and what would happen > prior to that patch in the same cases? >
NFS (and I think it is only NFS) returns NULL from ->lookup() without instantiating the dentry and without clearing DENTRY_PAR_LOOKUP if passed "LOOKUP_CREATE | LOOKUP_EXCL" or "LOOKUP_RENAME_TARGET". So when e.g. filename_create() calls lookup_one_qstr_excl() the result could be a d_in_lookup() dentry. It could be that the name exists on the server, but the client hasn't bothered to check. So determining that the result wasn't ERR_PTR(-EEXIST) does NOT assure us that the name doesn't exist. The intent needs to be attempted, such as when do_mknodat() goes on to call e.g. vfs_create(). Only once that returns an error can we know if the name existed. i.e. the API promise: + * Will return -EEXIST if name is found and LOOKUP_EXCL was passed. must be understood against the background that the name might not be found due to the lookup being short-circuited and not attempted. The other promise: + * Will return -ENOENT if name isn't found and LOOKUP_CREATE wasn't passed. is currently safe from confusion, but I can imagine that one day a LOOKUP_UNLINK intent could allow a filesystem to short-circuit the lookup in do_unlinkat() and simply send an UNLINK request to a server and return the result. So I thought it worth highlighting the fact that these errors are best-effort, and that d_in_lookup() is a real possibility. NeilBrown
