linux-next: manual merge of the nfs-anna tree with the nfs tree

linux-next: manual merge of the nfs-anna tree with the nfs tree

[Mark Brown]

[-- 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 --]

Re: linux-next: manual merge of the nfs-anna tree with the nfs tree

[Tim Menninger]

I tested the original reproducer on v7.3-rc4 and confirmed the issue was
present. I then applied the combined patch from Mark's merge resolution,
and the reproducer passed.

So at least for the issue I originally reported, the merge resolution
appears correct.

Thanks, Tim

linux-next: manual merge of the nfs-anna tree with the nfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Hi all,

Today's linux-next merge of the nfs-anna tree got a conflict in:

  net/sunrpc/xdr.c

between commit:

  0279024f2270 ("SUNRPC: Fix up xdr_set_page()")

from the nfs tree and commit:

  861b1da5a534 ("SUNRPC: Keep buf->len in sync with xdr->nwords when expanding holes")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/sunrpc/xdr.c
index c852d199c789,5b848fe65c81..000000000000
--- a/net/sunrpc/xdr.c
+++ b/net/sunrpc/xdr.c
@@@ -1316,8 -1326,8 +1317,8 @@@ uint64_t xdr_expand_hole(struct xdr_str
  					bytes);
  	_zero_pages(buf->pages, buf->page_base + offset, length);
  
- 	buf->len += length - (from - offset) - truncated;
+ 	buf->len += length - (from - offset);
 -	xdr_set_page(xdr, offset + length, PAGE_SIZE);
 +	xdr_set_page(xdr, offset + length, xdr_stream_remaining(xdr));
  	return length;
  }
  EXPORT_SYMBOL_GPL(xdr_expand_hole);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the nfs-anna tree with the nfs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Hi all,

Today's linux-next merge of the nfs-anna tree got a conflict in:

  fs/nfs/pagelist.c

between commit:

  df3accb84960 ("NFS: Pass error information to the pgio error cleanup routine")

from the nfs tree and commit:

  7517d01d20e1 ("FS: Pass error information to the pgio error cleanup routine")

from the nfs-anna tree.

I fixed it up (I just use the former version (since there are
other changes to this file in that tree)) 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.

There are a few common patches (as differetn commits) in these 2 trees,
so one should be cleaned up, please.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]