From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
commit f06d1b10cb016d5aaecdb1804fefca025387bd10 upstream.
Olga showed me a case where the client was sending multiple READ_PLUS
calls to the server in parallel, and the server replied
NFS4ERR_OPNOTSUPP to each. The client would fall back to READ for the
first reply, but fail to retry the other calls.
I fix this by removing the test for NFS_CAP_READ_PLUS in
nfs4_read_plus_not_supported(). This allows us to reschedule any
READ_PLUS call that has a NFS4ERR_OPNOTSUPP return value, even after the
capability has been cleared.
Reported-by: Olga Kornievskaia <kolga@xxxxxxxxxx>
Fixes: c567552612ec ("NFS: Add READ_PLUS data segment support")
Cc: stable@xxxxxxxxxxxxxxx # v5.10+
Signed-off-by: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
Reviewed-by: Benjamin Coddington <bcodding@xxxxxxxxxx>
Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/nfs/nfs4proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5320,7 +5320,7 @@ static bool nfs4_read_plus_not_supported
struct rpc_message *msg = &task->tk_msg;
if (msg->rpc_proc == &nfs4_procedures[NFSPROC4_CLNT_READ_PLUS] &&
- server->caps & NFS_CAP_READ_PLUS && task->tk_status == -ENOTSUPP) {
+ task->tk_status == -ENOTSUPP) {
server->caps &= ~NFS_CAP_READ_PLUS;
msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_READ];
rpc_restart_call_prepare(task);
Patches currently in stable-queue which might be from Anna.Schumaker@xxxxxxxxxx are
queue-5.10/nfs-fix-read_plus-when-server-doesn-t-support-op_read_plus.patch
