Files
linux/fs
Chuck Lever 18edc1d03c NFSD: Reset cb_seq_status after NFS4ERR_DELAY
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: 7ba6cad6c8 ("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>
2025-02-08 09:52:35 +01:00
..
2024-08-19 06:04:25 +02:00
2025-01-17 13:36:11 +01:00
2024-10-22 15:46:20 +02:00
2025-01-23 17:21:13 +01:00
2024-12-14 20:00:21 +01:00
2025-02-08 09:52:27 +01:00
2023-08-31 12:07:34 -05:00
2025-01-09 13:31:46 +01:00
2025-02-08 09:51:42 +01:00
2024-08-19 06:04:25 +02:00
2024-02-23 09:25:13 +01:00
2023-05-17 09:16:59 +02:00
2023-08-21 13:46:25 -07:00
2023-08-14 18:48:02 +02:00
2023-08-19 12:12:12 +02:00
2023-08-02 09:13:09 -06:00
2023-01-19 09:24:30 +01:00
2023-07-13 10:28:04 +02:00
2023-05-19 04:30:22 +02:00
2023-05-19 04:30:22 +02:00
2023-08-15 08:32:45 +02:00
2024-08-19 06:04:25 +02:00