From: Mark Brown <broonie@kernel.org>
To: Anna Schumaker <anna@kernel.org>,
Trond Myklebust <trondmy@gmail.com>,
NFS Mailing List <linux-nfs@vger.kernel.org>
Cc: Anna Schumaker <anna.schumaker@hammerspace.com>,
Chuck Lever <cel@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Tim Menninger <tmenninger@everpuredata.com>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Yongjian Mu <ymu@everpuredata.com>
Subject: linux-next: manual merge of the nfs-anna tree with the nfs tree
Date: Tue, 13 Oct 2026 12:47:53 +0100 [thread overview]
Message-ID: <as4aacUf2Q78FMvY@sirena.org.uk> (raw)
[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]
Hi all,
Today's linux-next merge of the nfs-anna tree got a conflict in:
net/sunrpc/xprtrdma/rpc_rdma.c
between commit:
a0db57fee35ec ("xprtrdma: Fix Write chunk payload corruption on a short reply header")
from the nfs tree and commit:
9ee534a759123 ("xprtrdma: trim head iovec when the payload arrives via a Write chunk")
from the nfs-anna tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
This one definitely needs double checking.
diff --combined net/sunrpc/xprtrdma/rpc_rdma.c
index ba8bdca8a49fb,7e5713367291e..0000000000000
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@@ -984,12 -984,16 +984,16 @@@ void rpcrdma_reset_cwnd(struct rpcrdma_
* @rqst: controlling RPC request
* @srcp: points to RPC message payload in receive buffer
* @copy_len: remaining length of receive buffer content
- * @pad: Write chunk pad bytes needed (zero for pure inline)
+ * @writelist: bytes conveyed by the Write chunk (zero for pure inline)
*
* The upper layer has set the maximum number of bytes it can
* receive in each component of rq_rcv_buf. These values are set in
* the head.iov_len, page_len, tail.iov_len, and buflen fields.
*
+ * For READ replies with a Write chunk, the payload is already in
+ * the page list. An overestimated head length and buflen can be
+ * reduced without moving reply data.
+ *
* Unlike the TCP equivalent (xdr_partial_copy_from_skb), in
* many cases this function simply updates iov_base pointers in
* rq_rcv_buf to point directly to the received reply data, to
@@@ -998,13 -1002,16 +1002,16 @@@
* Returns the count of bytes which had to be memcopied.
*/
static unsigned long
- rpcrdma_inline_fixup(struct rpc_rqst *rqst, char *srcp, int copy_len, int pad)
+ rpcrdma_inline_fixup(struct rpc_rqst *rqst, char *srcp, int copy_len,
+ u32 writelist)
{
unsigned long fixup_copy_count;
int i, npages, curlen;
char *destp;
struct page **ppages;
int page_base;
+ int pad = writelist & 3;
+ unsigned int delta;
/* The head iovec is redirected to the RPC reply message
* in the receive buffer, to avoid a memcopy.
@@@ -1016,8 -1023,20 +1023,20 @@@
* head.iov_len bytes are copied into the page list.
*/
curlen = rqst->rq_rcv_buf.head[0].iov_len;
- if (curlen > copy_len)
+ if (curlen > copy_len) {
+ /* These READ replies have no inline fields after the payload.
+ * Trim the head without moving the directly-placed data.
+ */
+ if (writelist) {
+ delta = curlen - copy_len;
+
+ rqst->rq_rcv_buf.head[0].iov_len = copy_len;
+ rqst->rq_private_buf.head[0].iov_len = copy_len;
+ rqst->rq_rcv_buf.buflen -= delta;
+ rqst->rq_private_buf.buflen -= delta;
+ }
curlen = copy_len;
+ }
srcp += curlen;
copy_len -= curlen;
@@@ -1243,19 -1262,9 +1262,19 @@@ rpcrdma_decode_msg(struct rpcrdma_xprt
/* Build the RPC reply's Payload stream in rqst->rq_rcv_buf */
base = (char *)xdr_inline_decode(xdr, 0);
- rpclen = xdr_stream_remaining(xdr);
+ rpclen = rep->rr_hdrbuf.len - xdr_stream_pos(xdr);
+ if (writelist)
+ rpclen &= ~3;
+ if (unlikely(!rpclen))
+ return -EIO;
+ if (writelist && rpclen < rqst->rq_rcv_buf.head[0].iov_len) {
+ rqst->rq_rcv_buf.head[0].iov_len = rpclen;
+ rqst->rq_private_buf.head[0].iov_len = rpclen;
+ }
+
r_xprt->rx_stats.fixup_copy_count +=
- rpcrdma_inline_fixup(rqst, base, rpclen, writelist);
+ rpcrdma_inline_fixup(rqst, base, rpclen,
+ xdr_pad_size(writelist));
r_xprt->rx_stats.total_rdma_reply += writelist;
return rpclen + xdr_align_size(writelist);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next reply other threads:[~2026-10-13 11:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 11:47 Mark Brown [this message]
2026-10-13 21:29 ` Tim Menninger
-- strict thread matches above, loose matches on Subject: below --
2020-12-06 23:31 Stephen Rothwell
2019-02-21 23:23 Stephen Rothwell
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=as4aacUf2Q78FMvY@sirena.org.uk \
--to=broonie@kernel.org \
--cc=anna.schumaker@hammerspace.com \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tmenninger@everpuredata.com \
--cc=trond.myklebust@hammerspace.com \
--cc=trondmy@gmail.com \
--cc=ymu@everpuredata.com \
/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
all inboxes | Powered by JetHome®