]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
nfsd: fix the slot sequence# when a callback fails
authorRick Macklem <rmacklem@FreeBSD.org>
Mon, 26 Apr 2021 23:24:10 +0000 (16:24 -0700)
committerRick Macklem <rmacklem@FreeBSD.org>
Mon, 26 Apr 2021 23:24:10 +0000 (16:24 -0700)
commit87597731488105dd1ab921a95e39bb62e1abe668
tree0b7f5a2470dda13d09d0520772acaf3226e69c83
parent43bbae19483fbde0a91e61acad8a6e71e334c8b8
nfsd: fix the slot sequence# when a callback fails

Commit 4281bfec3628 patched the server so that the
callback session slot would be free'd for reuse when
a callback attempt fails.
However, this can often result in the sequence# for
the session slot to be advanced such that the client
end will reply NFSERR_SEQMISORDERED.

To avoid the NFSERR_SEQMISORDERED client reply,
this patch negates the sequence# advance for the
case where the callback has failed.
The common case is a failed back channel, where
the callback cannot be sent to the client, and
not advancing the sequence# is correct for this
case.  For the uncommon case where the client's
reply to the callback is lost, not advancing the
sequence# will indicate to the client that the
next callback is a retry and not a new callback.
But, since the FreeBSD server always sets "csa_cachethis"
false in the callback sequence operation, a retry
and a new callback should be handled the same way
by the client, so this should not matter.

Until you have this patch in your NFSv4.1/4.2 server,
you should consider avoiding the use of delegations.
Even with this patch, interoperation with the
Linux NFSv4.1/4.2 client in kernel versions prior
to 5.3 can result in frequent 15second delays if
delegations are enabled.  This occurs because, for
kernels prior to 5.3, the Linux client does a TCP
reconnect every time it sees multiple concurrent
callbacks and then it takes 15seconds to recover
the back channel after doing so.

MFC after: 2 weeks
sys/fs/nfs/nfs_commonkrpc.c
sys/fs/nfs/nfs_commonsubs.c
sys/fs/nfs/nfs_var.h
sys/fs/nfsserver/nfs_nfsdstate.c