nfsclient: access v_mount only after the vnode is locked

[kib]

Summary

and we checked that it is not reclaimed.

[rmacklem]

Looks fine to me, rick

[rmacklem]

I do have a question?

How did v_data get referenced in the unpatched code?
Do you mean the NFS specific structure on the mount point?

[kib]

In D36722#833947, @rmacklem wrote:

I do have a question?

How did v_data get referenced in the unpatched code?
Do you mean the NFS specific structure on the mount point?

Sorry, it is v_mount not v_data. I fixed the commit message, thanks.

[markj]

sys/fs/nfsclient/nfs_clvnops.c

3925

If invp == outvp then the loop above will never terminate, and there is a double-unlock below. Probably it's better to handle that as a separate case at the beginning of the function, since we do not require the mountpoint mutex to check invp == outvp.

[kib]

Avoid invp == outvp case for locking vnodes.
Reorg and clean code, avoid using ap->a_XXX for locals.

[markj]

Looks ok to me. It seems rather wasteful that we have to uselessly acquire three mutexes each time VOP_COPY_FILE_RANGE is called on a NFSv3 mount. Was it ever considered to have separate vnode ops tables for different NFS major versions? I assume that the version is constant for the lifetime of the mount.

[rmacklem]

Looks fine to me. Good catch w.r.t. invp == outvp.

During development, NFSv4 compounds were based on NFSv3
RPCs, so they share a lot of code. It would not have made sense
to have a separate VOP table,

Now that NFSv4.2 has an assortment of operations unlike NFSv3,
it might make sense, for your example and others.