When returning NFSERR_BADSEQID, the server should not have incremented
the sequence ID, yet the call to nfsrv_checkseqid() a few lines above
does precisely that. Instead, check for a legitimate retransmission
of the original successful request, and reject otherwise, before the
ticket is used and sequence ID incremented.
MFC after: 1 week
Fixes: ff45b9fc1a ("Bjorn reported a problem...")
Sponsored by: Klara, Inc.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D61156
The write reduction code was broken in a few ways:
- It didn't handle non-zero b_dirtyoff.
- It didn't advance the uiop fields such that they could be
backed up for a retry.
- It didn't handle the rare retry case with a partially
written buffer.
This patch fixes the above and now write reduction seems
to be working ok.
MFC after: 1 month
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
Dropping the cached reply that is too large causes
a correctness problem that is too difficult to fix,
so revert this and leave it the way it was.
Although there is an argument that not doing could
cause resource exhaustion, it has not been reported
in the field as a problem.
MFC after: 1 month
When the offset is within a block rather than at its beginning, the
length should be clamped to the remaining length of the block, not its
total length.
Reported by: n0ps1ed
MFC after: 1 week
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D60904
When indexing the tarball on mount, fail if a file or directory name
exceeds MAXNAMLEN.
Reported by: n0ps1ed
Reported by: Franz Bettag <[email protected]>
MFC after: 1 week
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D60903
When a CREATE_SESSION with the extant ClientID failed with
NFS4ERR_STALE_CLIENTID within nfsc_renew of the previous full recovery,
nfsrpc_setclient() returned EIO and the mount did no I/O until that window
expired (about 45s).
The server has discarded the ClientID, so waiting cannot help; RFC 8881
Section 8.4.2 requires a new ClientID (EXCHANGE_ID) and a state reclaim.
AWS EFS discards both the session and the ClientID of clients whose lease is
current whenever it resets a connection, which makes this path common there.
PR: 299221
Approved by: rmacklem@
Sponsored by: Netflix
The NFSv4.1/4.2 session negotiates a limit to the size
of an RPC reply message that can be cached for the session
slot.
This patch fixes the code so that it checks that limit and
does not cache replies larger than the limit, even if the
client requested that it be cached.
This patch is slightly different than what the author
submitted, but retains the check for reply cache size limit.
Reviewed by: rmacklem
MFC after: 1 month
The calls to rpc_free_rdma_reduction() were removed, but I forgot
that newnfs_request() removes the reduction mbuf from the list
upon success, so it has to be free'd separately.
This patch does that.
The patch also disables reduction after the first loop interation.
This is necessary until nfsm_build_rdma_reduction() is patched
to handle an offset within the page array.
Reported by: markj
MFC after: 1 month
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
`ISO_RRIP_ANALYZE` is constructed in four places. Two of the
initializers set the `outlen` field while the other two,
`cd9660_rrip_analyze` and `cd9660_rrip_offset`, leave it uninitialized.
The uninitialized paths can dereference an invalid pointer on error
paths which causes a kernel panic.
To fix, I zero out `ISO_RRIP_ANALYZE` in all four places where it's
initialized and check that `outlen` is non-null on the error path
in `cd9660_rrip_loop`.
While testing the above, I encountered another kernel panic due to
mounting continuing after the error branch. Evidently, the ISO continued
mounting through the normal ISO 9660 path then triggered a panic down
the line due to a very broken file system from the ISO. To fix that, I
propagate the error from the RR path then fail in the mount path.
A previous iteration of this commit included the ISO from the PR. The
current iteration creates an ISO with makefs then corrupts it with a
small helper written in C that is a condensed version of the CD 9660
code. It checks the input ISO for a a Rock Ridge extension reference
then corrupts the length byte. This triggers the early failure in
cd9660_rrip_offset.
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296853
Signed-off-by: Josh Megnauth <[email protected]>
Reviewed-by: ngie
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2462
The calls to rpc_free_rdma_reduction() were cruft left over from
a previous variant of the NFS over RDMA client code. They resulted
in double free's of the reduction mbuf.
This patch gets rid of them and makes sure that reduction is only
done when an array of pages is provided, so that no anonymous pages
will be allocated.
The reduction mbuf is free'd with the rest of the argument mbuf list
in the client side krpc.
Suggested by: [email protected]
MFC after: 1 month
Fixes: 884ee8d6c9 ("nfscl: Add some glue for client side NFS over RDMA")
The write-permission check on the destination file in
nfsrvd_copy_file_range() and nfsrvd_clone() tested
NFSVNO_EXSTRICTACCESS() on the source export instead of the destination
export.
Rick notes:
The change is harmless and mostly meaningless.
NFSVNO_EXSTRICTACCESS() is a placeholder for some site that might
not want to let the file "owner" get access despite mode bits.
The "owner override" is a hack that has existed forever in NFS,
since applications often create files with O_WRONLY, but mode 444.
This works for POSIX, but would make NFS writes fail, since they
check mode on every write, instead of just at POSIX open(). The hack
is to always allow the file owner to have write access.
Without the hack, lots of applications would break over NFS, so I
doubt anyone would enable NFSVNO_EXSTRICTACCESS().
{ No one has ever even wanted an export flag for it. }
Reviewed by: rmacklem, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60952
Linux leaves the session's controlling terminal in place after the
last file descriptor on the slave is closed, so a later open of
/dev/tty succeeds. FreeBSD drops the session vnode reference on that
close. /dev/tty then fails, which breaks Linux programs such as xterm
that close the pty slave during startup and expect /dev/tty to keep
working.
When the closer is a Linux process, leave the session reference in
place. Still pass FLASTCLOSE to the driver so the master sees hangup.
Native close behavior is unchanged.
Add the SV_PERSISTENT_CTTY sysentvec flag for ABIs that retain the
controlling terminal after the last slave descriptor is closed. This
keeps the devfs behavior ABI-agnostic and allows other ABIs to request
the same semantics if needed. Use the flag in devfs_close().
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60701
When ERELOOKLUP is returned by a file operation
(always vop_lookup?) the operation is retried without
doing nfsrv_statsend().
This patch fixes this problem,
The only effect of the bug was bogus "nfsstat -d"
output.
PR: 298534
Reviewed by: rmacklem
MFC after: 1 week
In principle, inotify can be used to leak timing information about I/O
device accesses by privileged process, which might be sensitive, e.g.,
in the case of /dev/input. See https://inoti.fyi/#1-linux-inter-keystroke-timing
In practice this does not work since I/O to devfs nodes does not go
through vnodes, so the INOTIFY() calls in various VOP hooks do not fire.
But, let's explicitly define a no-op VOP_INOTIFY to help ensure that no
one tries to "fix" this bug.
Alternately we could simply ignore VCHR/VBLK vnodes in vn_inotify().
However, maybe someday it'll be desirable to enable inotify for specific
device files, in which case the filtering should live in devfs.
Add a regression test.
Reported by: Sudheendra Raghav Neela <[email protected]>
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D60364
We have identified some cases where silent slot loss can occur
when operations on NFS mounts are aborted. We experience this
when using NFSv4.2, but it likely also occurs with NFSv4.1.
A slot is acquired for compound operations by nfsv4_setsequence()
and freed by newnfs_request(). Any call path that abandons the
compound before reaching newnfs_request() loses the slot permanently.
We identified four call sites where this happens, one of
which where it actually does happen for us in a semi-reproducible
way, which allowed us to develop a candidate patch, attached.
The patch adds one function, nfsv4_freeunsentslot(), to
nfs_clcomsubs.c. It is called from each of the four call
sites: nfsrpc_writerpc(), nfsrpc_writeds(), and two in
nfsrpc_setextattr().
nfsv4_freeunsentslot() calls nfsv4_freeslot() with resetseq
set to true because the aborted RPC will never be sent and
therefore the slot sequence ID should not advance.
With this patch and other diagnostics, we have confirmed
that slot loss does not occur under the conditions that
otherwise cause it in our environment.
PR: 298416
Reviewed by: rmacklem
MFC after: 1 week
to make the opened device files non-passable.
Reviewed by: markj
Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D60285
I do not think that xp_p2 can be NULL at this point,
but add an extra safety belt, just in case.
Reviewed by: rmacklem
MFC after: 1 week
Sponsored by: VersatusHPC
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")
Assert that the refcount does not underflow before decrementing it, and
that it really is zero by the time the server is freed.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D60043
cuse_kern_uninit() can hang on destroy_dev(), because of threads
sleeping in CUSE_IOCTL_GET_COMMAND, so implement d_purge to wake them up
before calling destroy_dev(). Also do not allow threads to go back to
sleep if the is_closing flag has been set.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D60022
make_dev_s() sets si_drv1 before the node is published in devfs, which
avoids a race where cuse_client_open() could see it as NULL. It also now
reports finer-grained errors on failure, instead of only ENOMEM.
While here, drop the NULL checks on kern_dev in cuse_server_free_dev(),
since a device is only added to the server's list once it has been
created.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59874
Move cuse_server_unref()'s device cleanup loop into a new
cuse_server_free_devs_locked(), and call it from cuse_server_free()
instead. The cdevpriv destructor now destroys the server's devices
before dropping its reference, which closes the clients using them, so
that the destructor is always the one that takes the last reference.
By the time cuse_server_unref() frees the server, the device list should
be empty, so assert this.
In cuse_kern_uninit(), delete the infinite loop which waits for all open
/dev/cuse instances to exit, and instead call destroy_dev() directly,
which runs their cdevpriv destructor.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59872
Since we now use make_dev_credf(), make sure to fail kldload if it
returned NULL.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59863
We can call cuse_kern_init()/cuse_kern_uninit() here, rather than using
SYSINIT/SYSUNINIT.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59862
uiomove() leaves an iovec it has just emptied as the current one, so
cuse_client_read() and cuse_client_write() picked it up again on the
next iteration, sent the server a zero-length command, and got zero
bytes back. That left the residual count unchanged, so the loop never
terminated and the call never returned.
Step past empty iovecs at the start of every iteration. This also covers
caller-supplied zero-length iovecs, which hung in the same way
PR: 293489
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D59822
When an fdescfs mount has the nodup option set, fdesc_lookup(/dev/fd/n)
returns the vnode referenced by file descriptor n, rather than returning
an fdescfs vnode. This meant that fd metadata attached to fd n was not
preserved when reopening the file, which is contrary to the expected
semantics for capsicum rights and the UF_RESOLVE_BENEATH fd flag. For
regular fdescfs mounts, this metadata is copied via dupfdopen().
Fix the problem by passing up this metadata through the nameidata
structure. Thus, if one opens /dev/fd/n, the returned fd will inherit
UF_RESOLVE_BENEATH and the capability rights of fd n. Add some
regression tests as well.
Approved by: so
Security: FreeBSD-SA-26:66.jail
Security: CVE-2026-101304
Reported by: Jan Bramkamp
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59886
Wrap long lines, related to the nullfs mounts over regular files and
sockets type checks. Also fix indent.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
As result, we lock the devvp vnode around calls to VOP_FSYNC() on
unmount. For instance, the vn_fsync_buf() implementation of fsync()
needs exclusive lock on the vnode to guarantee that all dirty buffers
are indeed synced.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D59932
If a daemon never responds to FUSE_INIT, but some process attempts to
access the mountpoint, and a different process (possibly the daemon
itself) attempts to unmount, a deadlock would result.
Fix this bug by blocking any thread that enters fuse_vfsop_root until
the daemon responds to FUSE_INIT or it times out. That will block any
thread attempting to lookup a path in the fuse mountpoint, before it
even gets to fuse VOPs. Remove less thorough initialization checks in
fuse_ticket_fetch and fuse_vnop_access that are no longer necessary.
And add a test case.
PR: 287431
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: js
Differential Revision: https://reviews.freebsd.org/D59737
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")
Linux resolves a path below /proc/self/fd/N in the directory the
descriptor names, and linprocfs makes /proc/<pid>/fd a symlink to
/dev/fd. Under linrdlnk the fdescfs node carries only VV_READLINK,
which namei will not walk through, so such a path fails with ENOTDIR.
Return the underlying vnode from fdesc_lookup for a non-final component,
or a trailing slash, reusing the machinery the nodup option already
uses. The last component is untouched, so open("/dev/fd/N") keeps its
dup(2) semantic; a descriptor with no vnode behind it, such as a pipe,
yields ENOTDIR.
Add ATF coverage for traversal, descriptor reuse, and preservation of
last-component and mount-option semantics.
Approved by: adrian (mentor)
Reviewed by: kib, adrian
Differential Revision: https://reviews.freebsd.org/D59393
Signed-off-by: Nick Price <[email protected]>
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 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
In the world of containers, mounting a unix(4) socket is a common
practice to allow communication between processes within containers.
For example, both Podman and Docker can expose a unix(4) socket,
and that same unix(4) socket can be mounted as a file accessible
to a process inside a container, allowing that application to control
Podman or Docker. Another example is PHP-FPM with NGINX, where,
instead of using TCP/IP for communication between containers, a
unix(4) socket is sufficient.
However, nullfs(4) and all related components do not allow mounting
a VSOCK on top of another. The current workaround involves creating
the socket in a directory and mounting that directory. This is an
option, though it does not provide a good user experience compared
to directly mounting a VSOCK on top of another, since the application
that creates the socket may create other sockets in that directory,
and the user may not wish to share them, or, worse yet, applications
that create unix(4) sockets may not provide any authentication at
all, as they may assume that security at the file system level is
sufficient.
Reviewed by: dfr@
Approved by: dfr@
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D59158
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
As of commit 9f5c4ef328 ("dounmount(9): temporarily enable recursion
for the covered vnode lock"), the unmount path handles recursion
automatically, so there's no longer a need to handle this case
in unionfs-specific code.
Reviewed by: kib, markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D58858
Dag-Erling Smørgrav