Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Anna Schumaker <anna@kernel.org>
To:     linux-nfs@vger.kernel.org, chuck.lever@oracle.com
Cc:     anna@kernel.org, bfields@fieldses.org
Subject: [PATCH] NFSD: Don't continue encoding if READ_PLUS gets confused
Date:   Fri, 24 Jun 2022 11:47:37 -0400
Message-Id: <20220624154737.1387850-1-anna@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

From: Anna Schumaker <Anna.Schumaker@Netapp.com>

If we were in a HOLE segement, but vfs_llseek() claimed we were encoding
DATA then we would switch over to the DATA encoding function. This
conflicts with Chuck's latest xdr cleanup patches and can result in a
crash or silent hang. Let's just return nfserr_io if we find we are in
this situation, which will cause the encoder to return to the client
with the number of segments already encoded. The client can then try the
READ_PLUS call again.

Fxes: 6c254bf3b637 (SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer())
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
---
 fs/nfsd/nfs4xdr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index 61b2aae81abb..dc97d7c7e595 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -4792,7 +4792,7 @@ nfsd4_encode_read_plus_hole(struct nfsd4_compoundres *resp,
 	if (data_pos == -ENXIO)
 		data_pos = f_size;
 	else if (data_pos <= read->rd_offset || (data_pos < f_size && data_pos % PAGE_SIZE))
-		return nfsd4_encode_read_plus_data(resp, read, maxcount, eof, &f_size);
+		return nfserr_io;
 	count = data_pos - read->rd_offset;
 
 	/* Content type, offset, byte count */
-- 
2.36.1