kernel.git/net/sunrpc/xdr.c, branch linux-3.18.y

SUNRPC: drop pointless static qualifier in xdr_get_next_encode_buffer()

2018-11-27T15:05:37Z

[ Upstream commit 025911a5f4e36955498ed50806ad1b02f0f76288 ] There is no need to have the '__be32 *p' variable static since new value always be assigned before use it. Signed-off-by: YueHaibing Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin

sunrpc: correct the computation for page_ptr when truncating

2018-11-22T06:32:48Z

commit 5d7a5bcb67c70cbc904057ef52d3fcfeb24420bb upstream. When truncating the encode buffer, the page_ptr is getting advanced, causing the next page to be skipped while encoding. The page is still included in the response, so the response contains a page of bogus data. We need to adjust the page_ptr backwards to ensure we encode the next page into the correct place. We saw this triggered when concurrent directory modifications caused nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting call to xdr_truncate_encode() corrupted the READDIR reply. Signed-off-by: Frank Sorenson Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

rpc: fix xdr_truncate_encode to handle buffer ending on page boundary

2015-01-16T14:59:55Z

commit 49a068f82a1d30eb585d7804b05948376be6cf9a upstream. A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by: Holger Hoffstätte Tested-by: Holger Hoffstätte Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode" Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

SUNRPC: xdr_get_next_encode_buffer should be declared static

2014-07-18T15:35:46Z

Quell another sparse warning. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields

nfsd4: simplify server xdr->next_page use

2014-06-06T23:22:46Z

The rpc code makes available to the NFS server an array of pages to encod into. The server represents its reply as an xdr buf, with the head pointing into the first page in that array, the pages ** array starting just after that, and the tail (if any) sharing any leftover space in the page used by the head. While encoding, we use xdr_stream->page_ptr to keep track of which page we're currently using. Currently we set xdr_stream->page_ptr to buf->pages, which makes the head a weird exception to the rule that page_ptr always points to the page we're currently encoding into. So, instead set it to buf->pages - 1 (the page actually containing the head), and remove the need for a little unintuitive logic in xdr_get_next_encode_buffer() and xdr_truncate_encode. Signed-off-by: J. Bruce Fields

rpc: define xdr_restrict_buflen

2014-05-30T21:32:01Z

With this xdr_reserve_space can help us enforce various limits. Signed-off-by: J. Bruce Fields

nfsd4: allow encoding across page boundaries

2014-05-30T21:31:54Z

After this we can handle for example getattr of very large ACLs. Read, readdir, readlink are still special cases with their own limits. Also we can't handle a new operation starting close to the end of a page. Signed-off-by: J. Bruce Fields

rpc: xdr_truncate_encode

2014-05-30T21:31:47Z

This will be used in the server side in a few cases: - when certain operations (read, readdir, readlink) fail after encoding a partial response. - when we run out of space after encoding a partial response. - in readlink, where we initially reserve PAGE_SIZE bytes for data, then truncate to the actual size. Signed-off-by: J. Bruce Fields

rpc: Allow xdr_buf_subsegment to operate in-place

2014-03-29T01:24:49Z

Allow xdr_buf_subsegment(&buf, &buf, base, len) to modify an xdr_buf in-place. Also, none of the callers need the iov_base of head or tail to be zeroed out. Also add documentation. (As it turns out, I'm not really using this new guarantee, but it seems a simple way to make this function a bit more robust.) Signed-off-by: J. Bruce Fields

SUNRPC: Fix memory corruption issue on 32-bit highmem systems

2013-08-28T19:43:43Z

Some architectures, such as ARM-32 do not return the same base address when you call kmap_atomic() twice on the same page. This causes problems for the memmove() call in the XDR helper routine "_shift_data_right_pages()", since it defeats the detection of overlapping memory ranges, and has been seen to corrupt memory. The fix is to distinguish between the case where we're doing an inter-page copy or not. In the former case of we know that the memory ranges cannot possibly overlap, so we can additionally micro-optimise by replacing memmove() with memcpy(). Reported-by: Mark Young Reported-by: Matt Craighead Cc: Bruce Fields Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust Tested-by: Matt Craighead