]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
nfscl: Fix generation of va_fsid for a tree of NFSv4 server file systems
authorRick Macklem <rmacklem@FreeBSD.org>
Mon, 7 Jun 2021 20:48:25 +0000 (13:48 -0700)
committerRick Macklem <rmacklem@FreeBSD.org>
Mon, 7 Jun 2021 20:48:25 +0000 (13:48 -0700)
commit03c81af24920e14bd977f34edcd3eb7fb122db19
tree41eb0909e87749d126500dafaac026fb09bf663c
parent887c753c9f451322cae3efbf9b63f53f3d9011c8
nfscl: Fix generation of va_fsid for a tree of NFSv4 server file systems

Pre-r318997 the code looked like:
if (vp->v_mount->mnt_stat.f_fsid.val[0] != (uint32_t)np->n_vattr.na_filesid[0])
         vap->va_fsid = (uint32_t)np->n_vattr.na_filesid[0];
Doing this assignment got lost by r318997 and, as such, NFSv4 mounts
of servers with trees of file systems on the server is broken, due to duplicate
fileno values for the same st_dev/va_fsid.

Although I could have re-introduced the assignment, since the value of
na_filesid[0] is not guaranteed to be unique across the server file systems,
I felt it was better to always do the hash for na_filesid[0,1].
Since dev_t (st_dev/va_fsid) is now 64bits, I switched to a 64bit hash.

There is a slight chance of a hash conflict where 2 different na_filesid
values map to same va_fsid, which will be documented in the BUGS
section of the man page for mount_nfs(8).  Using a table to keep track
of mappings to catch conflicts would not easily scale to 10,000+ server file
systems and, when the conflict occurs, it only results in fts(3) reporting
a "directory cycle" under certain circumstances.

Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30660
sys/fs/nfsclient/nfs_clport.c