--- /dev/null
+From 961b4b5e86bf56a2e4b567f81682defa5cba957e Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Fri, 26 Jan 2024 12:45:17 -0500
+Subject: NFSD: Reset cb_seq_status after NFS4ERR_DELAY
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 961b4b5e86bf56a2e4b567f81682defa5cba957e upstream.
+
+I noticed that once an NFSv4.1 callback operation gets a
+NFS4ERR_DELAY status on CB_SEQUENCE and then the connection is lost,
+the callback client loops, resending it indefinitely.
+
+The switch arm in nfsd4_cb_sequence_done() that handles
+NFS4ERR_DELAY uses rpc_restart_call() to rearm the RPC state machine
+for the retransmit, but that path does not call the rpc_prepare_call
+callback again. Thus cb_seq_status is set to -10008 by the first
+NFS4ERR_DELAY result, but is never set back to 1 for the retransmits.
+
+nfsd4_cb_sequence_done() thinks it's getting nothing but a
+long series of CB_SEQUENCE NFS4ERR_DELAY replies.
+
+Fixes: 7ba6cad6c88f ("nfsd: New helper nfsd4_cb_sequence_done() for processing more cb errors")
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4callback.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/nfsd/nfs4callback.c
++++ b/fs/nfsd/nfs4callback.c
+@@ -1060,6 +1060,7 @@ static bool nfsd4_cb_sequence_done(struc
+ ret = false;
+ break;
+ case -NFS4ERR_DELAY:
++ cb->cb_seq_status = 1;
+ if (!rpc_restart_call(task))
+ goto out;
+