Commit 8b9775912cbc added support for an NFSv4 mounted
root file system, but only if the NFSv4 configuration
used id numbers in the strings.

This patch adds support for the case where the NFSv4
configuration uses name<-->id mappings via nfsuserd(8)
by priming the mapping cache with just enough entries
so that it works until the nfsuserd(8) is running.
They are listed in nfs_prime_userd[] in
sys/fs/nfs/nfs_commonsubs.c.

The entries in nfs_prime_userd[] are also wired into
the kernel's cache for name<-->id mappings when nfsuserd(8)
starts up.  This is necessary, since an upcall to the
nfsuserd(8) daemon for a mapping when looking up the
path to the passwd/group database files (/etc) will
hang the system, due to a vnode lock being held on
the entry in the path which blocks nfsuserd(8) from
accessing files.

To enable this case, the following must be put in the
NFS root file system's /boot/loader.conf:
boot.nfsroot.options="nfsv4"
boot.nfsroot.user_domain="<user.domain>"
where <user.domain> must be the same as nfsuserd
uses (usually set via the -domain flag).
If boot.nfsroot.user_domain does not exist or is
the empty string, ids is strings is configured.

MFC after:	1 week
Requested by:	Dan Shelton <dan.f.shelton@gmail.com>
Fixes:	8b9775912cbc ("nfs_diskless: Add support for an NFSv4 root fs")

This patch moves the definition of the nfsd_idargs
structure out of nfs.h and into a new file called
nfsid.h.

This is being done so that it can be included in
nfs_diskless.c in a future commit.

There should be no semantics change from this
commit.

MFC after:	1 week
Fixes:	8b9775912cbc ("nfs_diskless: Add support for an NFSv4 root fs")

Without this patch, diskless root NFS file systems
could only be mounted via NFSv3 (or NFSv2).
This patch adds the basic support needed to mount
a root fs via NFSv4.

At this time, the NFSv4 mount will only work if
the following is done on the NFS server configuration:
- The root directory specified in the "V4:" line in
  /etc/exports must be "/".  This is needed since the
  path to mount must be the same for NFSv3 and NFSv4.
- The NFS server must be configured to do both NFSv3
  and NFSv4, since the bootstrap code still uses NFSv3.
- The NFSv4 server must be configured with:
  vfs.nfs.enable_uidtostring=1
  vfs.nfsd.enable_stringtouid=1
  since the NFSv4 root fs cannot be running nfsuserd(8)
  when it is booting.  (This limitation may be removed
  in a future commit by hard-wiring enough id<-->name
  mapping entries to handle things until the nfsuserd(8)
  is running.)

To enable the root fs to be mounted via NFSv4, it needs:
- in the root file system's /boot/loader.conf
  boot.nfsroot.options="nfsv4"
  (Additional options like rsize=65536,wsize=65536 can
   also be specified.)
- in the root file system's /etc/sysctl.conf
  vfs.nfs.enable_uidtostring=1

Requested by:	Dan Shelton <dan.f.dhelton@gmail.com>
MFC after:	1 week

* cd9660_rrip_slink() did not check that the lengths of individual
  entries do not exceed the length of the overall record.

* cd9660_rrip_altname() did not check that the length of the record
  was at least 5 before subtracting 5 from it.

Note that in both cases, a better solution would be to check the length
of the data before calling the handler, or immediately upon entry of
the handler, but this would require significant refactoring.

MFC after:	1 week
Reported by:	Calif.io in collaboration with Claude and Anthropic Research
Reported by:	Adam Crosser, Praetorian
Reviewed by:	markj
Differential Revision:	https://reviews.freebsd.org/D56215

For some server file system types, such as ZFS, a Copy/Clone
operation can be done across file systems of the same file
system type.

However, without this patch, the Copy/Clone will fail with
EROFS if the input file is on a read-only mounted file system.
This happens because Copy/Clone will try to do a VOP_SETATTR()
of atime to set the atime.

This patch pretends the VOP_SETATTR() of atime worked for
read-only file systems.  It fixes a problem when copying
files from a ZFS snapshot.

PR:	294010
MFC after:	2 weeks

For some server file system types, such as ZFS, a Copy/Clone
operation can be done across file systems of the same file
system type.

As such, this patch allows the Copy/Clone to be attempted
when the file handles are for files on different file systems.

This fixes a problem for exported ZFS file systems when a
copy_files on file_range(2) between file systems in the same
NFSv4 mount is attempted.

PR:	294010
MFC after:	2 weeks

This mostly just fixes indentation and continuations and adds spaces
after commas and around binary operators and parentheses around return
values, but cd9660_rrip_extref() was so egregiously unreadable I
rewrote it.  Note that this was done manually, so I may have missed a
few spots, and I made no attempt to fix over-long lines.

MFC after:	1 week
Reviewed by:	markj
Differential Revision:	https://reviews.freebsd.org/D55865

An NFSv4.1/4.2 client can set/clear the archive, hidden
and system flags when creating non-regular files, such
as directories.

Without this patch, the setting of va_flags causes an
EPERM failure, since they are specified for VOP_MKDIR(),
VOP_MKNOD() and VOP_SYMLINK().

This patch sets va_flags == VNOVAL for the above VOP_xxx()
calls and then sets/clears the flags after creation,
which fixes the problem.

This bug only affects the Windows NFSv4.1/4.2 client.

PR:	293691
Tested by:	Dan Shelton <dan.f.shelton@gmail.com>
MFC after:	2 weeks

ZSTD_resetDStream() is deprecated since 1.5.4: https://github.com/facebook/zstd/commit/5d8cfa6b96a6442ab1251f9de3b47a0eb12561a0

This change is needed to MFV zstd 1.5.7.

Approved by:	emaste (mentor)
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D55835

Previously most fields in fuse_vnode_data were protected by the vnode
lock.  But because DEBUG_VFS_LOCKS was never enabled by default until
stable/15 the assertions were never checked, and many were wrong.
Others were missing.  This led to panics in stable/15 and 16.0-CURRENT,
when a vnode was expected to be exclusively locked but wasn't, for fuse
file systems that mount with "-o async".

In some places it isn't possible to exclusively lock the vnode when
accessing these fields.  So protect them with a new mutex instead.  This
fixes panics and unprotected field accesses in VOP_READ,
VOP_COPY_FILE_RANGE, VOP_GETATTR, VOP_BMAP, and FUSE_NOTIFY_INVAL_ENTRY.
Add assertions everywhere the protected fields are accessed.

Lock the vnode exclusively when handling FUSE_NOTIFY_INVAL_INODE.

During fuse_vnode_setsize, if the vnode isn't already exclusively
locked, use the vn_delayed_setsize mechanism.  This fixes panics during
VOP_READ or VOP_GETATTR.

Also, ensure that fuse_vnop_rename locks the "from" vnode.

Finally, reorder elements in struct fuse_vnode_data to reduce the
structure size.

Fixes:		283391
Reported by:	kargl, markj, vishwin, Abdelkader Boudih, groenveld@acm.org
MFC after:	2 weeks
Sponsored by:	ConnectWise
Reviewed by:	kib
Differential Revision: https://reviews.freebsd.org/D55230