From: Chuck Lever <chuck.lever@oracle.com>
To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH v1 01/10] svcrdma: Do not send XDR roundup bytes for a write chunk
Date: Wed, 03 Feb 2016 10:51:30 -0500 [thread overview]
Message-ID: <20160203155130.13868.17835.stgit@klimt.1015granger.net> (raw)
In-Reply-To: <20160203154411.13868.48268.stgit@klimt.1015granger.net>
When the Linux server writes an odd-length data item into a Write
chunk, it finishes with XDR pad bytes. If the data item is smaller
than the Write chunk, the pad bytes are written at the end of the
data item, but still inside the chunk. That can expose these zero
bytes to the RPC consumer on the client.
XDR pad bytes are inserted in order to preserve the XDR alignment
of the next XDR data item in an XDR stream. But Write chunks do not
appear in the payload XDR stream, and only one data item is allowed
in each chunk. So XDR padding is unneeded.
Thus the server should not write XDR pad bytes in Write chunks.
I believe this is not an operational problem. Short NFS READs that
are returned in a Write chunk would be affected by this issue. But
they happen only when the read request goes past the EOF. Those are
zero bytes anyway, and there's no file data in the client's buffer
past EOF.
Otherwise, current NFS clients provide a separate extra segment for
catching XDR padding. If an odd-size data item fills the chunk,
then the XDR pad will be written to the extra segment.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
net/sunrpc/xprtrdma/svc_rdma_sendto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
index df57f3c..8591314 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
@@ -308,7 +308,7 @@ static int send_write_chunks(struct svcxprt_rdma *xprt,
struct svc_rqst *rqstp,
struct svc_rdma_req_map *vec)
{
- u32 xfer_len = rqstp->rq_res.page_len + rqstp->rq_res.tail[0].iov_len;
+ u32 xfer_len = rqstp->rq_res.page_len;
int write_len;
u32 xdr_off;
int chunk_off;
next prev parent reply other threads:[~2016-02-03 15:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 15:51 [PATCH v1 00/10] NFS/RDMA server patches for v4.6 Chuck Lever
2016-02-03 15:51 ` Chuck Lever [this message]
2016-02-05 10:11 ` [PATCH v1 01/10] svcrdma: Do not send XDR roundup bytes for a write chunk Devesh Sharma
2016-02-03 15:51 ` [PATCH v1 02/10] svcrdma: Make svc_rdma_get_frmr() not sleep Chuck Lever
2016-02-05 10:15 ` Devesh Sharma
2016-02-05 16:29 ` Chuck Lever
2016-02-05 17:49 ` Devesh Sharma
2016-02-05 18:13 ` Chuck Lever
2016-02-06 15:56 ` Devesh Sharma
2016-02-03 15:51 ` [PATCH v1 03/10] svcrdma: svc_rdma_post_recv() should close connection on error Chuck Lever
2016-02-05 10:17 ` Devesh Sharma
2016-02-03 15:51 ` [PATCH v1 04/10] rpcrdma: Add missing XDR union fields for RDMA errors Chuck Lever
2016-02-05 10:23 ` Devesh Sharma
2016-02-05 15:53 ` Chuck Lever
2016-02-03 15:52 ` [PATCH v1 05/10] svcrdma: Make RDMA_ERROR messages work Chuck Lever
2016-02-05 10:35 ` Devesh Sharma
2016-02-03 15:52 ` [PATCH v1 06/10] svcrdma: Use correct XID in error replies Chuck Lever
2016-02-05 10:41 ` Devesh Sharma
2016-02-03 15:52 ` [PATCH v1 07/10] svcrdma: Hook up the logic to return ERR_CHUNK Chuck Lever
2016-02-05 10:45 ` Devesh Sharma
2016-02-03 15:52 ` [PATCH v1 08/10] svcrdma: Remove close_out exit path Chuck Lever
2016-02-05 10:41 ` Devesh Sharma
2016-02-03 15:52 ` [PATCH v1 09/10] svcrdma: Use new CQ API for RPC-over-RDMA server receive CQs Chuck Lever
2016-02-05 10:51 ` Devesh Sharma
2016-02-03 15:52 ` [PATCH v1 10/10] svcrdma: Use new CQ API for RPC-over-RDMA server send CQs Chuck Lever
2016-02-05 10:56 ` Devesh Sharma
2016-02-05 10:59 ` [PATCH v1 00/10] NFS/RDMA server patches for v4.6 Devesh Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160203155130.13868.17835.stgit@klimt.1015granger.net \
--to=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).