File system specific *fid structures are copied into the generic
struct fid defined in sys/mount.h.
As such, they cannot be larger than struct fid.
This patch packs the structure and checks via a __Static_assert().
Approved by: so
Security: FreeBSD-SA-25:02.fs
Reviewed by: markj
MFC after: 2 weeks
(cherry picked from commit 4db1b113b15158c7d134df83e7a7201cf46d459b)
(cherry picked from commit 155987e201)
File system specific *fid structures are copied into the generic
struct fid defined in sys/mount.h.
As such, they cannot be larger than struct fid.
This patch packed the structure and checks via a __Static_assert().
Approved by: so
Security: FreeBSD-SA-25:02.fs
Reviewed by: markj
MFC after: 2 weeks
(cherry picked from commit bfc8e3308bee23d0f7836d57f32ed8d47da02627)
(cherry picked from commit 7a3a0402ae)
File system specific *fid structures are copied into the generic
struct fid defined in sys/mount.h.
As such, they cannot be larger than struct fid.
This patch packs the structure and checks via a __Static_assert().
Approved by: so
Security: FreeBSD-SA-25:02.fs
Reported by: Kevin Miller <mas@0x194.net>
Reviewed by: olce, imp, kib, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47879
(cherry picked from commit 205659c43d87bd42c4a0819fde8f81e8ebba068e)
(cherry picked from commit 54974e731f)
REMOVE doesn't work properly in the face of hard links. Use UNLINKAT
instead, which is implemented by qemu and bhyve and lets the client
specify the name being removed.
PR: 282432
Reviewed by: dfr
Differential Revision: https://reviews.freebsd.org/D47438
This code is using the vnode after it has been released and causing a
panic when a p9fs shared volume is unmounted. In fact, it seems like it's
just duplicated code left behind from a bad merge.
PR: 279887
Reported by: Michael Dexter
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1323
Mostly copied from smbfs. This driver in its current state has the exact
same issue that prevents the generic putpages implementation from
working.
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: dfr
Differential Revision: https://reviews.freebsd.org/D45639
MFC after: 3 months
The lib9p implementation takes a strict interpretation of the Twalk RPC
call and returns an error for attempts to lookup ".". The workaround is
to fake the lookup locally.
Reviewed by: Val Packett <val@packett.cool>
MFC after: 3 months
This is derived from swills@ fork of the Juniper virtfs with many
changes by me including bug fixes, style improvements, clearer layering
and more consistent logging. The filesystem is renamed to p9fs to better
reflect its function and to prevent possible future confusion with
virtio-fs.
Several updates and fixes from Juniper have been integrated into this
version by Val Packett and these contributions along with the original
Juniper authors are credited below.
To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
bhyve virtio-9p device allows access from the guest to files on the host
by mapping a 'sharename' to a host path. It is possible to use p9fs as a
root filesystem by adding this to /boot/loader.conf:
vfs.root.mountfrom="p9fs:sharename"
for non-root filesystems add something like this to /etc/fstab:
sharename /mnt p9fs rw 0 0
In both examples, substitute the share name used on the bhyve command
line.
The 9P filesystem protocol relies on stateful file opens which map
protocol-level FIDs to host file descriptors. The FreeBSD vnode
interface doesn't really support this and we use heuristics to guess the
right FID to use for file operations. This can be confused by privilege
lowering and does not guarantee that the FID created for a given file
open is always used for file operations, even if the calling process is
using the file descriptor from the original open call. Improving this
would involve changes to the vnode interface which is out-of-scope for
this import.
Differential Revision: https://reviews.freebsd.org/D41844
Reviewed by: kib, emaste, dch
MFC after: 3 months
Co-authored-by: Val Packett <val@packett.cool>
Co-authored-by: Ka Ho Ng <kahon@juniper.net>
Co-authored-by: joyu <joyul@juniper.net>
Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net>
There has been a documented case in the exports(5) man
page forever, which specifies that the -maproot or -mapall
may have a single user entry, followed by a ':'.
This case is defined as specifying no groups (aka cr_ngroups == 0).
This patch fixes the NFS server so that it handles this case correctly.
After MFC'ng this patch to stable/13 and stable/14, I propose that
this unusual case be deprecated and no longer allowed in FreeBSD15.
At that point, this patch can be reverted.
(cherry picked from commit caa309c8811d62a24cd07e3a1f6e9095eaf10c90)
This reverts commit 9792c7d3eb.
The email thread "panic: nfsv4root ref cnt cpuid=1"
on freebsd-fs@freebsd.org descibes
crashes that occurred for a NFSv4.1 client mount
using "oneopenown" where the same file is re-opened
many times by different processes.
The crashes appear to have been caused by the use
of the Lookup+Open RPC (which only happens for
mounts using the "oneopenown" option).
There appears to be a race between closure of the
open and the open acquired by the Lookup+Open RPC.
Since Lookup+Open RPCs are only an optimization
and can only be done for "oneopenown" at this time,
this patch reverts enabling of them.
It may be possible to fix the code so that
Lookup+Open works reliably, so the code is left
in place (although it will never be executed) for now.
Reported by: J David <j.david.lists@gmail.com>
(cherry picked from commit 6df05714da160a8ac3e27ee34ff903bd0e760002)
nfsrv_freeopen() was being called after the mutex
lock was released, making it possible for other
kernel threads to change the lists while nfsrv_freeopen()
took the nfsstateid out of the lists.
This patch moves the code around
"if (nfsrv_freeopen(stp, vp, 1 p) == 0) {"
into nfsrv_freeopen(), so that it can remove the nfsstateid
structure from all lists before unlocking the mutex.
This should avoid any race between CLOSE and other nfsd threads
updating the NFSv4 state.
The patch does not affect semantics when vfs.nfsd.enable_locallocks=0.
PR: 280978
Tested by: Matthew L. Dailey <matthew.l.dailey@dartmouth.edu>
(cherry picked from commit eb345e05ac6602eeef0c33fce9025bbc8ec44d0f)
When processing an RPC response that did not include any Owner
attribute, nfsv4_loadattr would return na_uid and na_gid uninitialized.
The uninitialized values could then make their way into the NFS
attribute cache via nfscl_loadattrcache.
PR: 281279
Reported by: KMSAN
Reviewed by: rmacklem
Sponsored by: Axcient
(cherry picked from commit 44328abfb7aca8150b07b83ff502c9185677e3fb)
If the FUSE_GETATTR issued to query a file's size during
fuse_vnop_deallocate failed for any reason, then fuse_vnop_deallocate
would attempt to destroy an uninitialized fuse_dispatcher struct, with a
crash the likely result. This bug only affects FUSE file systems that
implement FUSE_FALLOCATE, and is unlikely to be seen on those that don't
disable attribute caching.
Reported by: Coverity Scan
CID: 1505308
(cherry picked from commit f93a50d69df2e996ff1d4f793d0dcb9de655ebdc)
Background:
If a user does pathconf(_, _PC_MIN_HOLE_SIZE) on a fusefs file system,
the kernel must actually issue a FUSE_LSEEK operation in order to
determine whether the server supports it. We cache that result, so we
only have to send FUSE_LSEEK the first time that _PC_MIN_HOLE_SIZE is
requested on any given mountpoint.
Problem 1:
Unlike fpathconf, pathconf operates on files that may not be open. But
FUSE_LSEEK requires the file to be open. As described in PR 278135,
FUSE_LSEEK cannot be sent for unopened files, causing _PC_MIN_HOLE_size
to wrongly report EINVAL. We never noticed that before because the
fusefs test suite only uses fpathconf, not pathconf. Fix this bug by
opening the file if necessary.
Problem 2:
On a completely sparse file, with no data blocks at all, FUSE_LSEEK with
SEEK_DATA would fail to ENXIO. That's correct behavior, but
fuse_vnop_pathconf wrongly interpreted that as "FUSE_LSEEK not
supported". Fix the interpretation.
PR: 278135
Sponsored by: Axcient
Differential Revision: https://reviews.freebsd.org/D44618
(cherry picked from commit 6efba04df3f8c77b9b12f1df3e5124a7249b82fc)
Commit d8a5961 made a change to nfsv4_sattr() that broke
parsing of the setable attributes for a NFSv4 SETATTR.
(It broke out of the code by setting "error" and returning
right away, instead of noting the error in nd_repstat and
allowing parsing of the attributes to continue.)
By returning prematurely, it was possible for SETATTR to return
the error, but with a bogus set of attribute bits set, since
"retbits" had not yet been set to all zeros.
(I am not sure if any client could be affected by this bug.
The patch was done for a failure case detected by a pynfs test
suite and not an actual client.)
While here, the patch also fixes a
few cases where the value of attributes gets set for attributes
after an error has been set in nd_repstat. This would not really
break the protocol, since a SETATTR is allowed to set some attributes
and still return an failure, but should not really be done.
(cherry picked from commit 5037c6398b2327366494a0434a894dc17ba8d023)
RFC8275 defines a new attribute as an extension to NFSv4.2
called MODE_UMASK. This patch adds the attribute number
to nfsproto.h.
Future patches will add optional support for the attribute.
This patch does not cause any semantics change.
(cherry picked from commit 10d5b43424da7fadfbdcc41bbffe40d130af1e1d)
The maximum cluster number was calculated based on the number of data
cluters that fit in the givem partition size and the size of the FAT
area. This limit did not take into account that the highest 10 cluster
numbers are reserved and must not be used for files.
PR: 280347
Reported by: pho@FreeBSD.org
(cherry picked from commit 45d4e82bf61f91792142a2b9e2af657dab8500fd)
The NFS RFCs are pretty loose with respect to what characters
can be in a filename returned by a Readdir. However, FreeBSD,
as a POSIX system will not handle imbedded '/' or nul characters
in file names. Also, for NFSv4, the file names "." and ".."
are handcrafted on the client and should not be returned by a
NFSv4 server.
This patch scans for the above in filenames returned by Readdir and
ignores any entry returned by Readdir which has them in it.
Because an imbedded nul would be a string terminator, it was
not possible to code this check efficiently using string(3)
functions.
Reported by: Apple Security Engineering and Architecture (SEAR)
(cherry picked from commit 026cdaa3b3a92574d9ac3155216e5cc0b0bd4c51)
Commit dfaeeacc2cc2 modified clientID handling so that it could be done
with only a mutex lock held when vfs.nfsd.enable_locallocks is 0.
This makes it unsafe to change the setting of vfs.nfsd.enable_locallocks
when nfsd threads are active.
This patch forces all nfsd threads to be blocked when the value
of vfs.nfsd.enable_locallocks is changed, so that it is done safely.
(cherry picked from commit 67284d32e5e0d5f015d73eeac4342974277263f5)
On Feb. 28, a problem was reported on freebsd-stable@ where a
nfsd thread processing an ExchangeID operation was blocked for
a long time by another nfsd thread performing a copy_file_range.
This occurred because the copy_file_range was taking a long time,
but also because handling a clientID requires that all other nfsd
threads be blocked via an exclusive lock, as required by ExchangeID.
This patch allows clientID handling to be done with only a mutex
held (instead of an exclusive lock that blocks all other nfsd threads)
when vfs.nfsd.enable_locallocks is 0. For the case of
vfs.nfsd.enable_locallocks set to 1, the exclusive lock that
blocks all nfsd threads is still required.
This patch does make changing the value of vfs.nfsd.enable_locallocks
somewhat racy. A future commit will ensure any change is done when
all nfsd threads are blocked to avoid this racyness.
(cherry picked from commit dfaeeacc2cc29d0497ecd4cd5b7fd0d5ab61fcd5)
On Feb. 28, a problem was reported on freebsd-stable@ where a
nfsd thread processing an ExchangeID operation was blocked for
a long time by another nfsd thread performing a copy_file_range.
This occurred because the copy_file_range was taking a long time,
but also because handling a clientID requires that all other nfsd
threads be blocked via an exclusive lock, as required by ExchangeID.
This patch adds two arguments to nfsv4_cleanclient() so that it
can optionally be called with a mutex held. For this patch, the
first of these arguments is "false" and, as such, there is no
change in semantics. However, this change will allow a future
commit to modify handling of the clientID so that it can be done
with a mutex held while other nfsd threads continue to process
NFS RPCs.
(cherry picked from commit a7de51068502ad1e2851d4a855ed28b27573bb36)
Since delegations are only issued for regular files, check
v_type to see if the query is for a regular file. This is
a simple optimization for the non-VREG case.
While here, fix a couple of global variable declarations.
This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.
(cherry picked from commit 4308d6e0fc09c807483f09b8fea7f5182d19fd01)
For NFSv4.1/4.2, an atomic upgrade of a delegation from a
read delegation to a write delegation is allowed and can
result in significantly improved performance.
This patch adds this upgrade to the NFSv4.1/4.2 client and
enables use of read delegations.
For a test case of building a FreeBSD kernel (sources and
output objects) over a NFSv4.2 mount, these changes reduced
the elapsed time by 30% and included a reduction of 80% for
RPC counts when delegations were enabled. As such, with this
patch there are at least certain cases where enabling
delegations seems to be worth the increased complexity they
bring.
This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.
(cherry picked from commit bb53f071e85a2ebb5b405e7fec4661a725b7caf5)
NFSv4.1/4.2 defined new OPEN_WANT_xxx flags that a client
can use to hint to the server that delegations are or are
not wanted. This patch adds use of those delegations to
the client.
This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.
(cherry picked from commit ec1f285f2e631b8aae3e08b3f68c6451a45c0941)
For NFSv4.1/4.2, an atomic upgrade of a delegation from a
read delegation to a write delegation is allowed and can
result in signoficantly improved performance.
This patch adds support for this atomic upgrade, plus fixes
a couple of other delegation related bugs. Since there were
three cases where delegations were being issued, the patch
factors this out into a separate function called
nfsrv_issuedelegations().
This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.
(cherry picked from commit e2c9fad2e0ae3f7049831bf7f2be1a3573363cdc)
During code inspection, I noticed that
NFSD_VNET_DEFINE(nfsrv_dontlisthead)
is unused, so delete it.
(cherry picked from commit 13a51233e4c7d6cff04043c38845b1ec1af38680)
RFC8881 specifies that, when a Link operation occurs on an
NFSv4, that file delegations issued to other clients must
be recalled. Discovered during a recent discussion on nfsv4@ietf.org.
Although I have not observed a problem caused by not doing
the required delegation recall, it is definitely required
by the RFC, so this patch makes the server do the recall.
Tested during a recent NFSv4 IETF Bakeathon event.
(cherry picked from commit 3f65000b6b1460a7a23cd83014bb41a68d1a8a19)
While here remove an old comment regarding preallocation; it appears to
refer to an optimization that is almost certainly irrelevant at this
point.
No functional change intended.
MFC after: 1 week
(cherry picked from commit 78c51db3c4927db2437ec616b33ba1faf73f08ee)
There is only one place in the unpatched sources where B_DIRECT is
set in the NFS client and this code is never executed. As such, this patch
removes this code that is never executed, since B_DIRECT should never
be set.
During a IETF testing event this week, I saw a crash in ncl_doio_directwrite(),
but this function is only called if B_DIRECT is set.
I cannot explain how ncl_doio_directwrite() got called, but once this patch
was applied to the sources, the crash did not recur. This is not surprising,
since this patch deleted the function.
(cherry picked from commit 03a39a17089adc1d0e28076670e664dcdebccf73)
When an initial attempt to close an NFSv4 lock returns NFSERR_DELAY,
the open structure is put on a list for delayed closing. When this
is done, the nfso_own field is set to NULL, so it cannot be used by
nfsrpc_doclose().
Without this patch, the NFSv4 client can crash when a NFSv4 server
replies NFSERR_DELAY to a Close operation. Fortunately, most extant
NFSv4 servers do not do this. This patch avoids the crash for any
that do return NFSERR_DELAY for Close.
Found during a IETF bakeathon testing event this week.
(cherry picked from commit 6251027c4252edb3b8f8fc359a40e610349e9af3)
This reverts commit f300335d9aebf2e99862bf783978bd44ede23550.
It turns out that the old code was correct and it was wireshark
that was broken and indicated that the RPC's XDR was bogus.
Found during IETF bakeathon testing this week.
(cherry picked from commit 54c3aa02e926268ba5551cd7d28fddf38b3589a2)
Commit 196787f79e67 erroneously assumed that the client code for
Open/Claim_deleg_cur_FH was broken, but it was not.
It was actually wireshark that was broken and indicated
that the correct XDR was bogus.
This reverts the part of 196787f79e67 that changed the arguments for
Open/Claim_deleg_cur_FH.
Found during the IETF bakeathon testing event this week.
(cherry picked from commit 8efba70d7914324890b1f8fe3079036eb2b5c3db)
There are a few spots in which unionfs_lookup() accesses unionfs vnode
private data without holding the corresponding vnode lock or interlock.
Reviewed by: kib, olce
Differential Revision: https://reviews.freebsd.org/D44601
(cherry picked from commit b18029bc59d2ed6b0eeeb233189cf713b34b467c)
If access from unreserved ports is disabled, then a remote host can
cause an NFS server to log a message by sending a packet. This is
useful for diagnosing problems but bad for resiliency in the case where
the server is being spammed with a large number of rejected requests.
Limit prints to once per second (racily).
Reviewed by: rmacklem, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44819
(cherry picked from commit b7e4666d7b69c22699a9299687018a892a5dad5b)
