git: c4e298251ab0 - main - nfscl: Handle the NFSERR_RETRYUNCACHEDREP error from a NFSv4 server

The branch main has been updated by rmacklem:

URL: https://cgit.FreeBSD.org/src/commit/?id=c4e298251ab01665f5bb3edeb740a51331818a45

commit c4e298251ab01665f5bb3edeb740a51331818a45
Author:     Rick Macklem <rmacklem@FreeBSD.org>
AuthorDate: 2023-10-18 19:42:12 +0000
Commit:     Rick Macklem <rmacklem@FreeBSD.org>
CommitDate: 2023-10-18 19:42:12 +0000

    nfscl: Handle the NFSERR_RETRYUNCACHEDREP error from a NFSv4 server
    
    In a recent email list discussion related to NFSv4 mount problems
    against a non-FreeBSD NFSv4 server, the reporter of the issue noted
    that the server had replied 10068 (NFSERR_RETRYUNCACHEDREP).  This
    did not seem related to the mount problem, but I had never seen this
    error before.  It indicates that an RPC retry after a new TCP
    connection has been established failed because the server did not
    cache the reply.  Since this should only happen for idempotent
    operations, redoing the RPC should be safe.
    
    This patch modifies the NFSv4.1/4.2 client to redo the RPC instead
    of considering the server error fatal.  It should only affect the
    unusual case where TCP connections to NFSv4 servers are breaking
    without the NFSv4 server rebooting.
    
    Reported by:    J David <j.devid.lists@gmail.com>
    MFC after:      2 weeks
---
 sys/fs/nfs/nfs_commonkrpc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sys/fs/nfs/nfs_commonkrpc.c b/sys/fs/nfs/nfs_commonkrpc.c
index 29c7cdbd671c..29fbb8dc4351 100644
--- a/sys/fs/nfs/nfs_commonkrpc.c
+++ b/sys/fs/nfs/nfs_commonkrpc.c
@@ -1300,7 +1300,8 @@ tryagain:
 			     nd->nd_procnum != NFSPROC_LOCKU))) ||
 			    (nd->nd_repstat == NFSERR_DELAY &&
 			     (nd->nd_flag & ND_NFSV4) == 0) ||
-			    nd->nd_repstat == NFSERR_RESOURCE) {
+			    nd->nd_repstat == NFSERR_RESOURCE ||
+			    nd->nd_repstat == NFSERR_RETRYUNCACHEDREP) {
 				/* Clip at NFS_TRYLATERDEL. */
 				if (timespeccmp(&trylater_delay,
 				    &nfs_trylater_max, >))