This patch adds some fields to NFS client side RDMA
structures and an additional argument to xprt_rdma_release_send().
This patch does not fix any semantics issue.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
When clnt_vc_destroy() is called, it might not be the
current connection. Without this patch, if it is not
the current connection, xp_p2 is set NULL and xprt is released
when it should not be released.
This patch adds a check for "current connection" to fix
the problem. Found during testing to the client RDMA code,
but could happen for TCP as well.
MFC after: 1 week
This patch updates the NFS client RDMA glue so that I/O
can be done directly to/from b_pages for buffer cache
blocks.
It also adds a flag to disable read reduction, that might
be needed against some non-FreeBSD servers and sets readahead
to 8 for RDMA unless the "readahead" option has been
specified.
This commit should not affect non-RDMA behaviour.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
Add a maxsegs field to rpcrdma_xprt, which is used to set
the number of segments allowed for a chunk based on device
attributes.
This commit should not affect non-RDMA behaviour.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
Without this patch, the code failed to acquire the error
return for clnt_bck_rdma_send() and could use "error" uninitialized.
No semantics change for non-RDMA NFS service.
MFC after: 3 months
Fixes: 7144a1d58c ("nfsd: Add glue for the nfsrdma.ko module")
Without this patch, nd_xprt is only set for NFSv4.1/4.2.
The nfsrdma.ko needs it to be set for all versions of NFS,
so this one line patch does that.
No semantics change for non-RDMA NFS service.
MFC after: 3 months
Fixes: 7144a1d58c ("nfsd: Add glue for the nfsrdma.ko module")
Yet again. I was trying to make the svc_vc_backchannel()
operations do double duty and be used by the clnt_rdma.c code
as well. It got too messy, so this reverts svc_vc.c back to
its pre-glue form and adds the small changes needed to support
a separate set of svc_rdma_backchannel_xxx() functions.
This commit should not affect non-RDMA behaviour.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
This should be it for a while, but there will be another cycle
of "glue" updates. I just found out that I'll need to create
an alternate code path that uses a contigmalloc() blob instead
of scatter/gather of pages, since some NICs cannot do the
scatter/gather of pages well.
This commit should not affect non-RDMA behaviour.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
Move svc_reg() calls into a helper function so that the nfsrdma.ko
can call that. Create a new nfs_extern.h as a place to put the
nfs stuff that server side NFS over RDMA needs to access, with a
prototype for the helper function and a couple of definitions that
probably shouldn't be in svc.h.
No semantics change.
MFC after: 3 months
Fixes: 7144a1d58c ("nfsd: Add glue for the nfsrdma.ko module")
A couple of additional fixes for the NFS client side RDMA glue:
- For Readdirplus, the reply needs to be a large chunk, so set
M_PROTO9 instead of M_PROTO8.
- The nfsclrdma.ko module now uses xprt_rdma_unmap_chunk()
instead of xprt_rdma_rekey_chunk().
Hopefully, this is it for the NFS over RDMA client glue changes.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
The OFED code checks for a vnet argument, but it is
is not defined.
Reported by: glebius
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
There were a couple of problems detected w.r.t. the
"glue" for the nfsclrdma.ko module.
- When the NFS server has a small reply for a read,
it can choose to not use the reduction chunk
(separate memory area for the read data). I did
not realize this was the case.
- There was a bug in rpc_copy_uio_pages() function
that caused intermittent crashes in memcpy().
This patch fixes the above cases. It uses M_PROTO6
to mark that an RPC reply has used a reduction chunk,
so that read can handle it correctly. Read also now
provides a reduction chunk for all read sizes, since
the worst case for the rest of the read RPC reply is
close to the 1024 byte limit. (NFSv4 uses strings
instead of uid/gid in the attributes and these name
strings can be rather large.)
I wanted to get the "glue" into main so that others
could test the module more easily. Avaliability of
the module will be announced on freebsd-current@ soon.
It should not affect non-RDMA operation.
I've specified a long MFC, since the module still
requires extensive testing and, hopefully, a review.
MFC after: 3 months
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
This patch adds a new nfs_client_rdma_enable variable
to /etc/rc.d/nfsclient to enable the client side of
NFS over RDMA. The client side of NFS over RDMA
requires the nfsclrdma.ko module, which is still under
test/review.
I wanted to get the "glue" into main so that others
could test the module more easily. Avaliability of
the module will be announced on freebsd-current@ soon.
It should not affect non-RDMA operation.
I've specified a long MFC, since the module still
requires extensive testing and, hopefully, a review.
MFC after: 3 months
This patch adds assorted bits needed by the nfsclrdma.ko
module that implements client side NFS over RDMA.
With this commit, the glue required by the nfsclrdma.ko
module is complete and it should load ok.
It should not affect non-RDMA operation.
I've specified a long MFC, since the module still
requires extensive testing and, hopefully, a review.
MFC after: 3 months
This patch adds assorted bits needed by the nfsclrdma.ko
module that implements client side NFS over RDMA.
It should not affect non-RDMA operation.
Some additional glue is needed for the nfsclrdma.ko
module within the NFS code. That will be added as
a separate commit.
I've specified a long MFC, since the module still
requires extensive testing and, hopefully, a review.
MFC after: 3 months
Commit 290e563166 changed the flag's name from dontcache
to nocache. This patch fixes the man page.
This is a content change.
Reviewed by: kib (earlier version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58181
Fixes: 4830670a3f ("chflags.1: Document the new UF_DONTCACHE flag")
This internet draft (which is close to being an RFC)
specifies a new NFSv4.2 attribute which tells the NFSv4.2
client to not cache file data. (Similar to O_DIRECT, but
triggered by this attribute set on the file on the NFSv4.2
server and not by the application's open(2).)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-uncacheable-files/
This patch adds a new chflags(1) flag called UF_NOCACHE to
implement this.
Patches for NFS and ZFS will be done separately.
This is a redo of the patch, with a requested name change
and a #ifdef in strtofflags.c so that it doesn't break some
Linux cross build. The name change was requested by fuz@.
Reviewed by: kib (earlier version)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58181
Commit 7144a1d58c added the hooks for the nfsrdma.ko module.
Once loaded, this module adds RDMA support to the nfsd.
This patch adds a few lines to /etc/rc.d/nfsd, so that
nfs_server_rdma_enable="YES"
in your /etc/rc.conf will load nfsrdma.ko, so that RDMA
service is enabled.
It also supports
nfs_server_rdma_listen="port#"
so that the default of 20490 can be overridden in /etc/rc.conf.
At this available as time, the nfsrdma.ko module is an unofficial port,
since it was developed by Vinicius Ferrao <[email protected]>
using generative AI.
As soon as it is available, it will be announced on
[email protected].
Suggested by: Vinicius Ferrao <versatushpc.com.br>
MFC after: 1 month
Thanks to Vinicius Ferrao <versatushpc.com.br>, there
is now a module that implements the server side of RDMA
for the FreeBSD NFS server.
At least for now, it will be maintained as an "unofficial
port" for FreeBSD, since it was built with generative AI
and FreeBSD is working on a policy related to these submissions.
This patch puts the "glue" needed by Vinicius's nfsrdma.ko
module in the system. This "glue" was written by me without
the use of AI.
The "unofficial port" of nfsrdma.ko will be advertised on
freebsd-current@ as soon as it is available.
(Vinicius's work was sponsored by VersatupHPC.)
Since newnfs_numnfsd is now declared extern in nfs.h,
the extern declaration can be removed from assorted files.
I'll do that as a separate commit.
Suggested by: Vinicius Ferrao <versatushpc.com.br>
MFC after: 1 month
Delegations in NFSv4.0 never worked well and, since
the NFSv4.0 protocol is now deprecated, use of delegations
for NFSv4.0 is disabled as far as the client can do so.
It turns out that some Illumos NFSv4.0 server issues
delegations anyhow (even when the callback path is
specified as 0.0.0.0) and this can cause use after free
problems.
This patch deleted some cruft that did an nfsrpc_openrpc()
call recursively when an NFSv4.0 server failed to issue
a delegation when it had previously done so.
This code was only meant to be an optimization and
would have been rarely exercised. Since this recursive
call of nfsrpc_openrpc() is in some of the backtraces
in the bugzilla PR, getting rid of the cruft makes sense.
It is not known if this helps w.r.t. the use after free
problems at this time.
PR: 297233
MFC after: 3 days
Commit 4d80d4913e added a check for nfsess_defunct already
being set. This was incorrect because, once set, nfsess_defunct
remains set and an additional recovery might be needed.
This patch reverts this part of 4d80d4913e.
PR: 297252
Suggested by: olivier
MFC after: 3 days
Fixes: 4d80d4913e ("nfs: Fix argument typo to avoid a crash")
Unlike RFC5661 (the original NFSv4.1 RFC), RFC8881 specifies
that a NFS4ERR_DELAY reply to the SEQUENCE operation requires
a reply using the same slot/sequence#.
This patch fixes handling of this case, so it conforms to
RFC8881.
Reported by: J. David ([email protected])
Tested by: J. David ([email protected])
MFC after: 1 week
This reverts commit 74654ba3b1.
Apparently it breaks cross building from Linux for some
reason. I'll admit I didn't even know we supported cross
building from Linux.
Commit 74654ba3b1 added and new chflags(1) flag called
"udontcache" or "dontcache". This patch documents this flag.
This is a content change.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58181
This internet draft (which is close to being an RFC)
specifies a new NFSv4.2 attribute which tells the NFSv4.2
client to not cache file data. (Similar to O_DIRECT, but
triggered by this attribute set on the file on the NFSv4.2
server and not by the application's open(2).)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-uncacheable-files/
This patch adds a new chflags(1) flag called UF_DONTCACHE to
implement this.
Patches for NFS and ZFS will be done separately.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D58181
Oops, I missed the other files for the commit.
This should fix the build.
Pointy hat goes on me.
MFC after: 2 weeks
Fixes: c52bcd09c2 ("nfsd: Garbage collect stray NFSv4 state")
When a file is deleted on the NFS server by another client,
any NFSv4 state related to that file is left stranded.
This happens because the NFSv4 operations that free the
state use a CFH, which is set by a PutFH operation.
However, the PutFH fails with ESTALE because the file has
been deleted.
This patch adds a function called nfsrv_freestrandedstate()
that frees all the NFSv4 state related to a file and calls
this function when PutFH will be replying ESTALE.
While here, a helper function was defined to handle free'ng
of the nfslockfile structure and replaces the two places
where nearly identical code does this.
Reported by: Richard Purdie <[email protected]>
Tested by: Michael Halstead <[email protected]>
MFC after: 2 weeks
A test site determined that, for a Mellanox NIC which can handle
M_EXTPG mbufs, an improvement of 5-15% for read rate could be
achieved if the read reply was in M_EXTPG mbufs.
A patch that tried to determine if the outbound NIC supported
M_EXTPG mbufs (IFCAP_MEXTPG) did not pass review.
However, it does appear that this can be useful for NFS-over-RDMA.
(Which just happen to use NICs that do support M_EXTPG mbufs.)
As such, this patch enables them is xp_extpg is set to true,
which is never for now, but might be set true for RDMA or
when vfs.nfsd.enable_mextpg is set non-zero. (It is 0 by
default, so this is never enabled by default at this time.)
Tested by: Greg Becker <[email protected]>
MFC after: 2 weeks
Commit 016570c446 modified the client to handle
the upgrade of a read delegation to a write delegation,
where the server provides the same delegation stateid
to the client. However, it failed to check if the
delegation structure was currently in use. Without this
patch, if the structure was in use, a use after free
could occur.
This patch handles the "in use" case by copying the
necessary fields into the current/old structure and
free's the new one instead of the old one that is
"in use".
PR: 296224
MFC after: 2 weeks
Recent testing with a modified NFSv4.1/4.2 client that
sometimes ignored CB_RECALL callbacks, identified a few
problems when handling the unusual case of CB_RECALL not
be performed by the client.
- The csa_cachethis argument to CB_SEQUENCE was being ignored.
- The CB_SEQUENCE operation would reply NFSERR_DELAY
after the first CB_RECALL attempt, making retries
ineffective.
- The code could return NFSERR_RESOURCE, which is a
NFSv4.0 specific error code.
This patch fixes the above three problems.
The patch only affects the NFSv4.1/4.2 client when
delegations are being issued and the client somehow
fails to handle a CB_RECALL callback of a delegation,
which is an unusual case.
MFC after: 2 weeks
Commit 72e57bc264 added support for striping to the pNFS
server configuration. This patch adds support for striping
to the NFS client.
For striped flexible file layouts, an extra structure
must be malloc()d for each stripe, since the number
of stripe servers can vary from one mirror to another.
This new structure is called nfsffs and a single one
of these structures is in the nfsffm structure so that
the non-striped layouts can avoid the additional malloc()'s.
This patch only affects NFSv4.1/4.2 mounts that use the
"pnfs" mount option against servers that support the
flexible file layout.
After the conversion to using netlink, the kgssapi had
no way of knowing if the gssd daemon was running.
As such, a boot where the kgssapi is loaded, but the
gssd is not enabled would hang the nfsd for a very
long time. (Many timeouts at 300sec each.)
This patch adds a Null RPC upcall with a 200msec
timeout to check to see if the gssd is running.
If the gssd is not running, the nfsd starts up
(without Kerberos support) with only a 200msec
delay.)
Also, move the svc_svc_nl_create() and svc_reg() calls in gssd.c
to before the daemon() call, so they are guaranteed to have
been done before the nfsd(8) daemon is started by
the rc scripts.
PR: 295714
Reviewed by: glebius
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57455
When an NFSv4.1/4.2 server is configured as a pNFS server,
new file creation (via Open/Create from an NFS client) is
slow, due to the fact that the NFS server (MDS) must do
RPCs against the DS(s).
This patch precreates files in a directory called ".pnfshide/numfiles",
so that the NFS server can just rename them for the Open/Create.
A kernel process called a "replenisher" creates more files in
".pnfshide/numfiles" as required. (At this point, the MDS must
still do Setattr RPC(s) on the DS(s), but that will change when
the pNFS server is converted to the loosely coupled configuration.
This patch only affects the pNFS server and only if the directory
.pnfshide/numfiles exists in the exported file system.
Reviewed by: kib
Discussed with: markj
Differential Revision: https://reviews.freebsd.org/D57554
Some ZFS pools do not support va_birthtime and will return
EINVAL when a VOP_SETATTR() of it is attempted. The MacOS
NFSv4 client sets va_birthtime (TimeCreate) in the same
Setattr with ctime/mtime and other attributes after a new
file is created. The EINVAL failure leaves these new files
messed up (mode == 0).
This patch pretends the setting of TimeCreate succeeded if
ctime/mtime were also set in the same Setattr RPC, which
resolves the problem for the MacOS client.
If this fix is not sufficient, a new pathconf name to detect
if a file system supports birthtime may be needed.
PR: 296066
Tested by: Will <[email protected]>
MFC after: 2 weeks
Commits c5d72d2 and 3b6d4c6 broke the case where the
archive/hidden/system attributes are being set false
(UF_ARCHIVE, UF_HIDDEN or UF_SYSTEM bits being cleared.)
and the NFS server does not support those attributes.
These patches only checked for support if the
archive/hidden/system attributes were non-zero.
This patch fixes the problem.
PR: 296088
Tested by: Joshua Kinard <[email protected]>
MFC after: 1 week
Fixes: c5d72d29fe ("nfsv4: Add support for the NFSv4 hidden and system attributes")
This reverts commit 7a289fe3cd.
Hopefully, commit fc7993cf2d has fixed the underlying
problem reported by PR#289734, so I am reverting this
temporary work-around.
I will delay MFC'ng this for a while, to see if the
problem occurs again.
MFC after: 3 months
This patch moves "struct netexport" into a separate
netexport.h file and refcounts the structure, plus adds
a few fields that will be used in a future NFS server
commit.
The patch also includes some helper functions for
handling the netextport structure:
vfs_netexport_alloc(), vfs_netexport_acquire(),
vfs_netexport_release() and vfs_netexport_reset().
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D57553
Commit 72e57bc264 added support for striping to the pNFS
server when using the Flexible File layout.
It is configured globally via the following sysctls:
vfs.nfsd.pnfsstripeunit - Size (in bytes) of a stripe
vfs.nfsd.pnfsstripecnt - # of DSs to stripe across
This patch allows the above settings to be overridden
on a per-MDS exported file system basis. With this
patch, a stripeunit can optionally be specified for
the MDS file system listed when one is listed after
a '#' in the "-p" nfsd argument. This is done by
appending "@NNN", where NNN is the stripeunit, in bytes.
The current syntax implies that neither a '#' nor '@'
can be in the MDS mount point's directory path.
This patch does not affect current pNFS server
configurations (of which there appears to be very
few, anyhow).
Commit 4d80d4913e fixed a long standing bug in the recovery
code. However. glebius@ reported seeing multiple
recovery cycles with this patch during an NFSv4.1/4.2
server reboot.
This commit should minimize the risk of multiple
recovery cycles.
PR: 294925
Reported by: Jov <[email protected]>
MFC after: 2 weeks
Fixes: 4d80d4913e ("nfs: Fix argument typo to avoid a crash")
Without this patch, the NFSv4.1/4.2 pNFS server configuration
did not support striping. This was mainly because the Linux
client driver did not support it either. The Linux client
driver for Flexible File layout does now support striping.
(Linux kernel version 6.18 or newer)
As such, this patch adds striping support. The configuration
is currently just two new sysctls called
vfs.nfsd.pnfsstripeunit - Size (in bytes) of a stripe
vfs.nfsd.pnfsstripecnt - # of DSs to stripe across
A setting of 0 for the first sysctl and 1 for the second
disables striping. A patch that allows use of a different
striping configuration for each exported MDS file system
is planned for the future.
The pnfsdscopymr may be broken by this patch, but since
no one reported that they were actually using a pNFS server
configuration, I do not believe that will be a problem at
this time.
Until the FreeBSD NFSv4.1/4.2 client is patched to handle
striped flexible file layouts, mounts to a striped pNFS
configuration must be done without the "pnfs" mount option.
(Linux systems with a kernel version of 6.18 or newer
should be able to handle a striped pNFS configuration.)
Future patches that convert the pNFS server to a
"loosely coupled" configuration (which allows the use
of non-FreeBSD servers as DSs) are anticipated.
Since the File 4.1 layout is only supported by some
large configurations of Netapp Filers, switch the client
pNFS code to attempting to use Flexible File Format first.
File 4.1 Layout should still work for any servers that do
no support Flexible File Layout.
A typo resulted in the wrong argument for a bytewise
comparison that could result in a crash if
the incorrect argument was not a valid pointer.
This patch fixes the argument.
While investigating this, I noticed that the
correct argument was not being filled in as
required, so this patch fixes that, as well.
Somehow, recovery from a NFSv4.1/4.2 server
crash worked during testing, so this was not
detected. The bug/patch only affects NFS
client mounts using NFSv4.1/4.2.
PR: 294925
Reported by: Jov <[email protected]>
MFC after: 3 days
Without this patch, the maximum setting for
vfs.nfsd.srvmaxio was 1Mbyte. This patch increases
that to 4Mbytes.
The same as for any setting above 128Kbytes, settings up to
4Mbytes require that kern.ipc.maxsockbuf be increased.
(A message generated after setting vfs.nfsd.srvmaxio via
the /etc/rc.conf variable nfs_server_maxio will indicate
the minimum setting, which will be somewhat greater than
four times the setting of vfs.nfsd.srvmaxio.)
Requested by: Cedric Blancher <[email protected]>
MFC after: 2 weeks
Fixes: 13d3bd165e ("subr_uio.c: Remove a KASSERT() for large NFS server I/O")
When the NFS server is set to allow an I/O size greater
than 1Mbyte (not allowed in FreeBSD's main yet), a
KASSERT() in allocuio() can fail when:
zfs_freebsd_write()->zfs_write()->zfs_uiocopy()
->cloneuio()->allocuio()
is called for a large NFS server write.
Since the userland API callers to allocuio() already
check that the size does not exceed UIO_MAXIOV,
there does not seem to be a need to a KASSERT()
here.
Removing the KASSERT() allows NFS server writes
of greater than 1Mbyte to work, once the NFS code
is patched to allow them.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57005
In ncl_getcookie(), a very large value for "off" for
a directory can result in "pos" being set to a bogus
value (including a negative one), due to truncation.
When "pos" is negative, is can skip past the
while (pos >= NFSNUMCOOKIES) loop and return a
bogus pointer instead of NULL.
This patch changes the type to u_int and also adds
a sanity check for a very large "off" to ensure that
a NULL pointer is returned for this case.
This bug has been in the code for decades and I am
not aware of any report of it causing a problem for
users.
Reviewed by: markj
Reported by: Joshua Rogers of AISLE Research Team
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56779
The client tells the server how many callback slots
it can handle in the callback session. However, the
NFSv4.1/4.2 server can only handle a maximum of
NFSV4_SLOTS slots. This patch clips the client's
value to that, to avoid using too high a slot#
for a callback.
Fortunately, I do not know of an extant client that
specifies a value greater than NFSV4_SLOTS, so this
patch is not really needed, as yet. Also, the client
rarely uses a slot# above 0 when doing callbacks.
MFC after: 2 weeks
Commit 71ac1ec5c9 disabled callbacks for the NFS
client for NFSv4.0. This patch does the same for
the NFSv4.0 server.
The only use for callbacks for NFSv4.0 is delegations
and delegations rarely work well for NFSv4.0 anyhow.
Therefore, this patch disables callbacks for the
NFSv4.0 server. This is the same behavior as
occurs when vfs.nfsd.issue_delegations is 0.
This change allowed the functions called
nfsrv_getclientipaddr() and nfsrv_getipnumber() to be
removed from the kernel.
MFC after: 2 weeks
When the krpc was vnet'd, the VNET macros were hidden
behind macros that had the KRPC_ prefix on them.
This was done because, at the time, it was thought
that something other than vnet might be used for this.
That has not happened and probably will not happen,
so this patch replaces these obscuring macros with
the regular vnet ones.
There should be no semantics change caused by
this commit.
Discussed with: bz, glebius
MFC after: 1 month
When the nfsd was vnet'd, the VNET macros were hidden
behind macros that had the NFSD_ prefix on them.
This was done because, at the time, it was thought
that something other than vnet might be used for this.
That has not happened and probably will not happen,
so this patch replaces these obscuring macros with
the regular vnet ones.
There should be no semantics change caused by
this commit.
Discussed with: bz, glebius
MFC after: 1 month
Without this patch, all upcalls to the gssd daemon are
done in vnet0 (outside of any vnet jail). This does
not work well, because a user principal's credential
cache can be within the jail (/tmp/krb5cc_NNN in the
jail's namespace).
This patch modifies the client so that RPCs done
from within vnet jails does an upcall to a gssd
daemon running within the vnet jail. It required
that the cache of uid->credential shorthands in
the rpcsec_gss be vnet'd.
The situation is still less than ideal and sec=krb5[ip]
mounts that are visible within vnet jails is still
not something I would recommend, but it can work ok
with this patch.
Vnet'ng the NFS client so that mounts can be done
within vnet jails is probably more useful, but that
will require additional work.
Discussed with: glebius
MFC after: 1 month
The only use for callbacks for NFSv4.0 is delegations
and delegations rarely work well for NFSv4.0 anyhow.
Therefore, this patch disables callbacks for the
NFSv4.0 client. This is the same behavior as
occurred when the nfscbd(8) daemon was not running.
This change allowed a function called nfscl_getmyip()
to be removed from the kernel, which is nice since
maintaining this function was bothersome, due to its
use of routing, etc.
MFC after: 2 weeks
Commit 8b9775912c added support for an NFSv4 mounted
root file system. This patch documents how to set this
up. It also includes some minor updates and fixes
some formatting.
This is a content change.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56317
Fixes: 8b9775912c ("nfs_diskless: Add support for an NFSv4 root fs")
Commit 8b9775912c 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 <[email protected]>
Fixes: 8b9775912c ("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: 8b9775912c ("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 <[email protected]>
MFC after: 1 week
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
There were two debug printf()s that were left in the
code while debugging the handling of callbacks over
a NFSv4.1/4.2 backchannel was being done.
This patch removes them, since they are no longer
of benefit and cause "noise".
Requested by: wollman
MFC after: 2 weeks
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 <[email protected]>
MFC after: 2 weeks
When an NFSv4.1/4.2 sarver upgrades a read delegation to
a write delegation, it does not need to change the
delegation's stateid.
Without this patch, a DELEGRETURN of the stateid was done
for the case where the delegation stateid had not changed.
This return was bogus, since the delegation stateid now
represents the new write delegation.
This patch fixes the priblem by checking for "same stateid"
and only doing the DELEGRETURN when it is not the same.
PR: 289711
Tested by: Peter Much <[email protected]_sub.org>
MFC after: 2 weeks
PR#293198 reports a hang within ZFS when exports
are being updated concurrently with a VOP_SETEXTATTR().
The hang appears to be caused by mishandling of the
z_teardown_lock, but fixing handling of this lock appears
to be a major effort. Since the hang occurs when
VFS_MOUNT() acquires a write/exclusive z_teardown_lock,
which rarely occurs, except when exports are being updated,
this patch avoids the VFS_MOUNT() call for this case.
Avoiding a VFS_MOUNT() call fixes the hang for the case
reported by PR#293198 and is also an optimization.
As such, this patch avoids the VFS_MOUNT() call when only exports
are being updated similar to what was already being done
within vnet prisons.
PR: 293198
Reviewed by: kib, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55318
Bugzilla PR#292282 reports a problem, where a Linux
binary running in the Linuxulator gets bogus entries
in a readdir()/getdents() reply when the directory is
an NFS mount.
This appears to be caused by the NFS client including
entries with d_fileno == 0, which are always ignored by
BSD, but are not ignored by Linux.
This patch filters out the "d_fileno == 0" entries and
the reporter of the bugzilla PR notes that it fixes the
problem for him.
It could be argued that the NFS client should filter out
the "d_fileno == 0" entries, but the NFS client readdir
code is "fragile" and any change to it runs a significant
risk of causing regression type problems.
As such, since the LInuxulator is already broken for this
case, it seems safer to filter them out there.
PR: 292282
Tested by: Jerry Williams <[email protected]>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D54679
Lionel Cons <[email protected]> requested
that a new option be added to runat(1) so that it could
be used to manipulate named attributes associated with
a symbolic link and not the file the symbolic link refers to).
This patch adds the option -h/--nofollow to do this.
Requested by: Lionel Cons <[email protected]>
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55023
Name caching must be handled somewhat differently
for case insensitive file systems. Negative name
caching does not work and, for rename, all names
associated with the rename'd vnode must be disabled.
For a case insensitive ZFS file system that is exported,
the unpatched code did work, since the change in mtime
or ctime of the directory when other case names were
created or rename'd would disable the false name cache
hit. However, an export of an msdosfs file system
breaks the NFS client, because it only works if ctime/mtime
is changed whenever a name is added/removed. Depending
on what the server file system is, this may not happen,
due to clock resolution or lack of support for these
attributes.
This patch checks to see if the server file system is
case insensitive and modifies the name caching to handle
this.
There is still a problem if a case insensitive file system
is a subtree of a non-case insensitive is exported by the
NFSv4 server. This can be fixed someday, when the NFSv4
client gets support for submounts within the mount.
Suggested by: kib
MFC after: 2 weeks
When an NFSv4.n client specifies settings for attributes other
mode during a Open/Create/Exclusive_41, these other attributes
were not being set.
This patch resolves the problem by calling nfsrv_fixsattr()
after the VOP_CREATE() call in nfsvno_open() for this case.
There is no extant NFSv4.n client that currently does this,
as far as I know.
MFC after: 2 weeks
When an NFSv4.n client specifies settings for the archive,
hidden and/or system attributes during a Open/Create, the
Open/Create fails for ZFS. This is caused by ZFS doing
a secpolicy_xvattr() call, which fails for non-root.
If this check is bypassed, ZFS panics.
This patch resolves the problem by disabling va_flags
for the VOP_CREATE() call in the NFSv4.n server and
then setting the flags with a subsequent VOP_SETATTR().
This problem only affects FreeBSD-15 and main, since the
archive, system and hidden attributes are not enabled
for FreeBSD-14.
I think a similar problem exists for the NFSv4.n
Open/Create/Exclusive_41, but that will be resolved
in a future commit.
Note that the Linux, Solaris and FreeBSD clients
do not set archive, hidden or system for Open/Create,
so the bug does not affect mounts from those clients.
PR: 292283
Reported by: Aurelien Couderc <[email protected]>
Tested by: Aurelien Couderc <[email protected]>
MFC after: 2 weeks
A POSIX draft default ACL may not exist. As such,
an ACL with zero ACEs needs to be allowed.
This patch fixes acquisition of POSIX draft default
ACLs when they do not exist on the directory.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
The nfsd can be configured to support NFSv3, NFSv4 or both
of them.
This patch adds a short paragraph to nfsd.8 to explain this.
This is a content change.
Reviewed by: kib, zaiee (manpages)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54279
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the final patch in the series that enables
the extension of NFSv4.2 to support POSIX draft ACLs.
At this time, only UFS mounted with the "acls" option
will work, and only for FreeBSD built with these patches.
Patches for client and server for the Linux kernel are
in the works. (I'll admit my next little project is
cleaning the Linux patches up for submission for upstream.)
To make these changes really useful, the FreeBSD port
of OpenZFS needs to be patched to add POSIX draft ACL
support. (Support for POSIX draft ACLs is already in
the Linux port of OpenZFS.)
Interopeability with NFSv4.2 clients and servers that
do not support this extension should not be a problem.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the fifth of several patches that implement the
above draft.
This one mostly adds an extra argument to two functions
in nfscommon.ko. Unfortunately, these functions are
called in many places, so the changes are numerous, but
straightforward.
Since the internal KAPI between the NFS modules is changed
by this commit, all of nfscommon.ko, nfscl.ko and nfsd.ko
must be rebuilt from sources.
There should be no semantics change for the series at
this point.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the fourth of several patches that implement the
above draft.
There should be no semantics change for the series at
this point.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the third of several patches that implement the
above draft.
There should be no semantics change for the series at
this point.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the second of several patches that implement the
above draft.
The only semantics change would be if you have exported
a UFS file system mounted with the "acl" option.
In that case, you would see the acl attribute supported.
This is bogus, but will be handled in the next commit.
Fixes: a35bbd5d9f ("nfscommon: Add some support for POSIX draft ACLs")
An internet draft (expected to become an RFC someday)
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-posix-acls
describes an extension to NFSv4.2 to handle POSIX draft ACLs.
This is the first of several patches that implement the
above draft.
This patch should not result in a semantics change.
Bugzilla PR reported a crash caused by a synthetic client
doing a Lock operation request with a delegation stateid.
This patch fixes the problem by adding sanity checks
for the type of stateid provided as an argument to the
Lock and LockU operations.
It has been tested with the FreeBSD, Linux and Solaris 11.4
clients. Hopefully, other NFSv4 clients will work ok
as well.
PR: 291080
Tested by: Robert Morris <[email protected]>
MFC after: 2 weeks
Commit e5aa60d069 changed the internal KAPI between
the NFS modules. As such, they all need to be rebuilt
from sources. Bump __FreeBSD_version to 1600004 for this.
Commit d6864221d8 added support for the _PC_CASE_INSENSITIVE
name for pathconf, to indicate if case insensitive lookups
are configured.
This patch adds support for it for both NFSv4 and
NFSv3.
It also adds a fsidp argument to nfsv4_fillattr() which
will be used in future commit(s) related to NFSv4.n
directory delegations.
MFC after: 2 weeks
Commit d6864221d8 added support for the _PC_CASE_INSENSITIVE
name for pathconf, to indicate if case insensitive lookups
are configured.
This patch documents this new name and also updates
the description for _PC_HAS_HIDDENSYSTEM to also
include UF_ARCHIVE.
This is a content change.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D53508
Without this patch, the NFS client code for mounts has
an arbitrary 100 character limit for the directory path
being mounted on the server.
Someone reported this quite a while ago, but I cannot
find the email or bugzilla PR.
This patch fixes the problem by increasing the directory
path length limit to MNAMELEN, allocated via malloc() to
avoid using too much stack.
MFC after: 2 weeks
The variable ncl_mbuf_mhlen is set to MHLEN and only
used in one place. This patch simply deletes it and
replaces it with MHLEN.
This patch should not affect semantics.
Spotted while fixing cases that could do large
NFSM_DISSECT() sizes.
MFC after: 2 weeks
Without this patch, the entire reply for all directories in
the NFSv4 mount path are parsed at once. This could cause
problems for mount paths with many directories in the path.
This patch fixes the problem by parsing each directory
reply in a loop.
Spotted while fixing other cases that could do large
NFSM_DISSECT() sizes.
MFC after: 3 days
The nfsuserd(8) daemon passes user credentials
(uid + gids) into the kernel for users and groups
identified by name (received from a NFSv4 server).
This patch add a sanity check for the number of
groups (nid_ngroup) passed in.
It's only purpose is to protect against a bogus
nfsuserd(8) running in a jail.
Reported by: Ilja Van Sprundel <[email protected]>
Reviewed by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53389
The "rlen" reply length for a Write operation/RPC
could cause trouble if a broken server replies with
too large a value.
Improve the sanity check for "rlen" to avoid this.
Reported by: Ilja Van Sprundel <[email protected]>
Reviewed by: emaste, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53368
Rick Macklem