History log of /freebsd/sys/fs/nfsserver/nfs_nfsdstate.c (Results 1 – 25 of 242)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 84de8c51 10-Jan-2025 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Add vfs.nfsd.testing_disable_grace sysctl

The grace time of 2 minutes plus when the nfsd is started
is needed for normal operation. It allows client(s) to
recovery open/lock state. However,

nfsd: Add vfs.nfsd.testing_disable_grace sysctl

The grace time of 2 minutes plus when the nfsd is started
is needed for normal operation. It allows client(s) to
recovery open/lock state. However, for testing situations
where there are no client(s) to recover state, it introduces
an unacceptable delay.

The new per-vnet jail sysctl can be set non-zero to disable
the grace period. It should only be used for testing and
can be applied on a per-jail basis. It must be set before
the nfsd is started up.

Requested by: asomers
Tested by: asomers

show more ...


Revision tags: release/14.2.0
# eb345e05 01-Oct-2024 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix close handling when vfs.nfsd.enable_locallocks=1

nfsrv_freeopen() was being called after the mutex
lock was released, making it possible for other
kernel threads to change the lists while

nfsd: Fix close handling when vfs.nfsd.enable_locallocks=1

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>
MFC after: 1 week

show more ...


Revision tags: release/13.4.0
# dfaeeacc 23-Jun-2024 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Allow a mutex lock for clientID handling

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 nfs

nfsd: Allow a mutex lock for clientID handling

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.

MFC after: 1 month

show more ...


# a7de5106 22-Jun-2024 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix nfsrv_cleanclient so that it can be called with a mutex

On Feb. 28, a problem was reported on freebsd-stable@ where a
nfsd thread processing an ExchangeID operation was blocked for
a long

nfsd: Fix nfsrv_cleanclient so that it can be called with a mutex

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.

MFC after: 1 month

show more ...


# e2c9fad2 05-Jun-2024 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix delegation handled for atomic upgrade

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 pe

nfsd: Fix delegation handled for atomic upgrade

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.

MFC after: 1 month

show more ...


Revision tags: release/14.1.0
# 54c3aa02 25-Apr-2024 Rick Macklem <rmacklem@FreeBSD.org>

Revert "nfsd: Fix NFSv4.1/4.2 Claim_Deleg_Cur_FH"

This reverts commit f300335d9aebf2e99862bf783978bd44ede23550.

It turns out that the old code was correct and it was wireshark
that was broken and i

Revert "nfsd: Fix NFSv4.1/4.2 Claim_Deleg_Cur_FH"

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.

show more ...


Revision tags: release/13.3.0, release/14.0.0
# f300335d 19-Oct-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix NFSv4.1/4.2 Claim_Deleg_Cur_FH

When I implemented a test patch using Open Claim_Deleg_Cur_FH
I discovered that the NFSv4.1/4.2 server was broken for this
Open option. Fortunately it is ne

nfsd: Fix NFSv4.1/4.2 Claim_Deleg_Cur_FH

When I implemented a test patch using Open Claim_Deleg_Cur_FH
I discovered that the NFSv4.1/4.2 server was broken for this
Open option. Fortunately it is never used by the FreeBSD
client and never used by other clients unless delegations
are enabled. (The FreeBSD NFSv4 server does not have delegations
enabled by default.)

Claim_Deleg_Cur_FH was broken because the code mistakenly
assumed a stateID argument, which is not the case.
This patch fixes the bug by changing the XDR parser to not
expect a stateID and to fill most of the stateID in from the
clientID. The clientID is the first two elements of the "other"
array for the stateID and is sufficient to identify which
client the delegation is issued to. Since there is only one
delegation issued to a client per file, this is sufficient to
locate the correct delegation.

If you are running non-FreeBSD NFSv4.1/4.2 mounts against the
FreeBSD server, you need this patch if you have delegations enabled.

PR: 274574
MFC after: 2 weeks

show more ...


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 11892bc7 02-Aug-2023 Gordon Bergling <gbe@FreeBSD.org>

nfsserver: Fix a typo in a source code comment

- s/restared/restarted/

MFC after: 3 days


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


# ff2f1f69 07-Apr-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Add support for the SP4_MACH_CRED case in ExchangeID

Commit f4179ad46fa4 added support for operation bitmaps for
NFSv4.1/4.2. This commit uses those to implement the SP4_MACH_CRED
case for th

nfsd: Add support for the SP4_MACH_CRED case in ExchangeID

Commit f4179ad46fa4 added support for operation bitmaps for
NFSv4.1/4.2. This commit uses those to implement the SP4_MACH_CRED
case for the NFSv4.1/4.2 ExchangeID operation since the Linux
NFSv4.1/4.2 client is now using this for Kerberized mounts.
The Linux Kerberized NFSv4.1/4.2 mounts currently work without
support for this because Linux will fall back to SP4_NONE,
but there is no guarantee this fallback will work forever.

This commit only affects Kerberized NFSv4.1/4.2 mounts from
Linux at this time.

MFC after: 3 months

show more ...


Revision tags: release/13.2.0
# 695d87ba 29-Mar-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfscl: Make coverity happy

Coverity does not like code that checks a function's
return value sometimes. Add "(void)" in front of the
function when the return value does not matter to try
and make i

nfscl: Make coverity happy

Coverity does not like code that checks a function's
return value sometimes. Add "(void)" in front of the
function when the return value does not matter to try
and make it happy.

A recent commit deleted "(void)"s in front of nfsm_fhtom().
This commit puts them back in.

Reported by: emaste
MFC after: 3 months

show more ...


# 896516e5 16-Mar-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts

Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time. This credential
i

nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts

Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time. This credential
is typically referred to as a "machine credential". It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
is done and this becomes the machine credential.
There are two problems with this.
1 - The user doing the mount must have a valid TGT for a user
principal at mount time. As such, the mount cannot be put
in fstab(5) or similar.
2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
file and this service principal (typically called a host-based
initiator credential) is used as the machine credential.
There are problems with this approach as well:
1 - There is a certain amount of administrative overhead creating
the service principal for the NFS client, creating a keytab
entry for this principal and then copying the keytab entry
into the client's default keytab file via some secure means.
2 - The NFS client must have a fixed, well known, DNS name, since
that FQDN is in the service principal name as the instance.

This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos). As such, neither of the above
mechanisms is needed.

It is hoped that this option will encourage adoption of Kerberized
NFS mounts using TLS, to provide a more secure NFS mount.

This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.

Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server. As such, this option allows, at most, a
malicious client to do some sort of DOS attack.

Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.

A mount_nfs(8) man page update will be done in a separate commit.

Discussed on: freebsd-current@
MFC after: 3 months

show more ...


# b039ca07 16-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Wrap nfsstatsv1_p in the NFSD_VNET() macro

Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
The nfsstatsv1_p variable got misse

nfsd: Wrap nfsstatsv1_p in the NFSD_VNET() macro

Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
The nfsstatsv1_p variable got missed. This patch wraps all
uses of nfsstatsv1_p with the NFSD_VNET() macro.
The NFSD_VNET() macro is still a null macro.

MFC after: 3 months

show more ...


# 7e44856e 12-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Prepare the NFS server code to run in a vnet prison

This patch defines null macros that can be used to apply
the vnet macros for global variables and SYSCTL flags.
It also applies these macros

nfsd: Prepare the NFS server code to run in a vnet prison

This patch defines null macros that can be used to apply
the vnet macros for global variables and SYSCTL flags.
It also applies these macros to many of the global variables
and some of the SYSCTLs. Since the macros do nothing, these
changes should not result in semantics changes, although the
changes are large in number.

The patch does change several global variables that were
arrays or structures to pointers to same. For these variables,
modified initialization and cleanup code malloc's and free's
the arrays/structures. This was done so that the vnet footprint
would be about 300bytes when the macros are defined as vnet macros,
allowing nfsd.ko to load dynamically.

I believe the comments in D37519 have been addressed, although
it has never been reviewed, due in part to the large size of the patch.
This is the first of a series of patches that will put D37519 in main.

Once everything is in main, the macros will be defined as front
end macros to the vnet ones.

MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D37519

show more ...


Revision tags: release/12.4.0
# aa41036e 23-Jun-2022 Elliott Mitchell <ehem+freebsd@m5p.com>

nfsserver: purge EOL release compatibility

Remove now-obsolete FreeBSD 4.x and earlier ifdef.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/603
Differential Revision: h

nfsserver: purge EOL release compatibility

Remove now-obsolete FreeBSD 4.x and earlier ifdef.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/603
Differential Revision: https://reviews.freebsd.org/D35560

show more ...


# 5a0050e6 15-Jan-2023 Rick Macklem <rmacklem@FreeBSD.org>

nfsserver: Fix handling of SP4_NONE

For NFSv4.1/4.2, when the client specifies SP4_NONE for
state protection in the ExchangeID operation arguments,
the server MUST allow the state management operati

nfsserver: Fix handling of SP4_NONE

For NFSv4.1/4.2, when the client specifies SP4_NONE for
state protection in the ExchangeID operation arguments,
the server MUST allow the state management operations for
any user credentials. (I misread the RFC and thought that
SP4_NONE meant "at the server's discression" and not MUST
be allowed.)

This means that the "sec=XXX" field of the "V4:" exports(5)
line only applies to NFSv4.0.

This patch fixes the server to always allow state management
operations for SP4_NONE, which is the only state management
option currently supported. (I have patches that add support
for SP4_MACH_CRED to the server. These will be in a future commit.)

In practice, this bug does not seem to have caused
interoperability problems.

MFC after: 2 weeks

show more ...


# a75d1ddd 17-Sep-2022 Mateusz Guzik <mjg@FreeBSD.org>

vfs: introduce V_PCATCH to stop abusing PCATCH


# b875d4f5 28-Aug-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Update console message for no session found

The NFSv4.1/4.2 server generates a console message that indicates
that there is no session. I was until recently perplexed w.r.t. how
this could occ

nfsd: Update console message for no session found

The NFSv4.1/4.2 server generates a console message that indicates
that there is no session. I was until recently perplexed w.r.t. how
this could occur. It turns out that the common cause is multiple NFS
clients with the same /etc/hostid.

The host uuid is used by the FreeBSD NFSv4.1/4.2 client as a unique
identifier for the client. If multiple clients use the same host uuid,
this indicates to the NFSv4.1/4.2 server that they are the same client
and confusion occurs.

This trivial patch modifies the console message to suggest that the
client's /etc/hostid needs to be checked for uniqueness.

Reviewed by: asomers
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36377

show more ...


# 088ba435 14-Jul-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix CreateSession for an established ClientID

I mis-read the RFC w.r.t. handling of the sequenceid
when a CreateSession is done after the initial one
that confirms the ClientID. Fortunately t

nfsd: Fix CreateSession for an established ClientID

I mis-read the RFC w.r.t. handling of the sequenceid
when a CreateSession is done after the initial one
that confirms the ClientID. Fortunately this does
not affect most extant NFSv4.1/4.2 clients, since
they only acquire a single session for TCP for a
ClientID (Solaris might be an exception?).

This patch fixes the server to handle this case,
where the RFC requires the sequenceid be incremented
for each CreateSession and is required to reply to
a retried CreateSession with a cached reply.
It adds a field to nfsclient called lc_prevsess,
which caches the sessionid, which is the only field
in a CreateSession reply that will change for a
retry, to implement this reply cache.

The recent commits up to d4a11b3e3bdd that mark
session slots bad when "intr" and/or "soft" mounts
are used by the client needs this server patch.
Without this patch, the client will do a full
recovery, including a new ClientID, losing all
byte range locks. However, prior to the recent
client commits, the client would hang when all
session slots were bad, so even without this
patch it is not a regression.

PR: 260011
MFC after: 2 weeks

show more ...


# 40ada74e 09-Jul-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfscl: Add optional support for slots marked bad

This patch adds support for session slots marked bad
to nfsv4_sequencelookup(). An additional boolean
argument indicates if the check for slots mark

nfscl: Add optional support for slots marked bad

This patch adds support for session slots marked bad
to nfsv4_sequencelookup(). An additional boolean
argument indicates if the check for slots marked bad
should be done.

The "cred" argument added to nfscl_reqstart() by
commit 326bcf9394c7 is now passed into nfsv4_setquence()
so that it can optionally set the boolean argument
for nfsv4_sequencelookup(). When optionally enabled,
nfsv4_setsequence() will do a DestroySession when all
slots are marked bad.

Since the code that marks slots bad is not yet committed,
this patch should not result in a semantics change.

PR: 260011
MFC after: 2 weeks

show more ...


# 5d3fe02c 22-Jun-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Clean up the code by not using the vnode_vtype() macro

The vnode_vtype() macro was used to make the code compatible
with Mac OSX, for the Mac OSX port.
For FreeBSD, this macro just obscured th

nfsd: Clean up the code by not using the vnode_vtype() macro

The vnode_vtype() macro was used to make the code compatible
with Mac OSX, for the Mac OSX port.
For FreeBSD, this macro just obscured the code, so
avoid using it to clean up the code.

This commit should not result in a semantics change.

show more ...


Revision tags: release/13.1.0
# 271f6d52 02-May-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Fix session slot freeing for NFSv4.1/4.2

Without this patch the NFSv4.1/4.2 server erroneously
always frees session slot zero for callbacks. This only
affects 4.1/4.2 mounts if the server has

nfsd: Fix session slot freeing for NFSv4.1/4.2

Without this patch the NFSv4.1/4.2 server erroneously
always frees session slot zero for callbacks. This only
affects 4.1/4.2 mounts if the server has delegations
enabled or is a pNFS configuration. Even for those
cases, the effect is mainly to only use slot 0 for
callbacks, serializing all of them. There is a slight
chance that callbacks will fail if the client performs
them in a different order than received on the TCP
connection.

If this bug affects your server, you will see console
messages like:
newnfs_request: Bad session slot

This patch fixes the problem. Found during a recent
IETF NFSv4 testing event.

PR: 263728
MFC after: 2 weeks

show more ...


# 17a56f3f 10-Feb-2022 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Reply NFSERR_SEQMISORDERED for bogus seqid argument

The ESXi NFSv4.1 client bogusly sends the wrong value
for the csa_sequence argument for a Create_session operation.
RFC8881 requires this va

nfsd: Reply NFSERR_SEQMISORDERED for bogus seqid argument

The ESXi NFSv4.1 client bogusly sends the wrong value
for the csa_sequence argument for a Create_session operation.
RFC8881 requires this value to be the same as the sequence
reply from the ExchangeID operation most recently done for
the client ID.

Without this patch, the server replies NFSERR_STALECLIENTID,
which is the correct response for an NFSv4.0 SetClientIDConfirm
but is not the correct error for NFSv4.1/4.2, which is
specified as NFSERR_SEQMISORDERED in RFC8881.
This patch fixes this.

This change does not fix the issue reported in the PR, where
the ESXi client loops, attempting ExchangeID/Create_session
repeatedly.

Reported by: asomers
Tested by: asomers
PR: 261291
MFC after: 1 week

show more ...


# c302f889 14-Dec-2021 Rick Macklem <rmacklem@FreeBSD.org>

nfsd: Limit parsing of layout errors to maxcnt bytes

This patch decrements maxcnt by the appropriate
number of bytes during parsing and checks to see
if there is data remaining. If not, it just ret

nfsd: Limit parsing of layout errors to maxcnt bytes

This patch decrements maxcnt by the appropriate
number of bytes during parsing and checks to see
if there is data remaining. If not, it just returns
from nfsrv_flexlayouterr() without further processing.
This prevents the tl pointer from running off the end
of the error data pointed at by layp, if there are
flaws in the data.

Reported by: rtm@lcs.mit.edu
Tested by: rtm@lcs.mit.edu
PR: 260293
MFC after: 2 weeks

show more ...


12345678910