Re: why is short-circuiting nfs_lookup() for mkdir(2) et.al. dependent upon v3 or later?

[Trond Myklebust <trondmy@hammerspace.com>]

On Tue, 2021-03-30 at 00:48 +0000, Al Viro wrote:
>         In nfs_lookup() we have
>         /*
>          * If we're doing an exclusive create, optimize away the
> lookup
>          * but don't hash the dentry.
>          */
>         if (nfs_is_exclusive_create(dir, flags) || flags &
> LOOKUP_RENAME_TARGET)
>                 return NULL;
> OK, fair enough - we don't need to find out whether it's negative or
> not for
> mkdir() et.al.; if it isn't, server will tell us to sod off and we
> can live
> with not having it in cache - in the worst case, we'll have to do the
> same
> lookup we'd skipped here at some later point.  Same for rename(2)
> destination -
> if it wasn't in dcache, we are not going to bother with sillyrename
> anyway, and
> that's the only thing where we might care about the destination.  If
> rename(2)
> succeeds, we won't see whatever had been there anyway, and if it
> fails, we won't
> lose anything from having lookup done later.
> 
>         What I don't get is why, unlike rename(2) target, mkdir(2)
> argument is
> handled that way only for v3 and later.  It's been a long time since
> I looked
> at NFSv2 servers, but shouldn't we get NFSERR_EXIST if the sucker
> turns out to
> have already been there?
> 
>         What am I missing?

The check for NFS version > 2 is mainly there for the case of CREATE,
which does not have an exclusive create mode in NFSv2.
IOW: I believe we can indeed rely on LINK, MKDIR, and RENAME returning
NFSERR_EXIST, but not the more common case of CREATE.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com