NFS: Fix READ_PLUS when server doesn't support OP_READ_PLUS
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@netapp.com> Fixes: c567552612ec ("NFS: Add READ_PLUS data segment support") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
278f1f7c03
commit
51e5124d93
1 changed files with 1 additions and 1 deletions
|
@ -5320,7 +5320,7 @@ static bool nfs4_read_plus_not_supported(struct rpc_task *task,
|
|||
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);
|
||||
|
|
Loading…
Reference in a new issue