linux-stable.git/net/sunrpc, branch v3.18.32

sunrpc/cache: fix off-by-one in qword_get()

2016-03-08T06:14:06+00:00

[ Upstream commit b7052cd7bcf3c1478796e93e3dff2b44c9e82943 ]

The qword_get() function NUL-terminates its output buffer.  If the input
string is in hex format \xXXXX... and the same length as the output
buffer, there is an off-by-one:

  int qword_get(char **bpp, char *dest, int bufsize)
  {
      ...
      while (len < bufsize) {
          ...
          *dest++ = (h << 4) | l;
          len++;
      }
      ...
      *dest = '\0';
      return len;
  }

This patch ensures the NUL terminator doesn't fall outside the output
buffer.

Signed-off-by: Stefan Hajnoczi 
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

svcrdma: Fix send_reply() scatter/gather set-up

2015-10-28T02:13:29+00:00

[ Upstream commit 9d11b51ce7c150a69e761e30518f294fc73d55ff ]

The Linux NFS server returns garbage in the data payload of inline
NFS/RDMA READ replies. These are READs of under 1000 bytes or so
where the client has not provided either a reply chunk or a write
list.

The NFS server delivers the data payload for an NFS READ reply to
the transport in an xdr_buf page list. If the NFS client did not
provide a reply chunk or a write list, send_reply() is supposed to
set up a separate sge for the page containing the READ data, and
another sge for XDR padding if needed, then post all of the sges via
a single SEND Work Request.

The problem is send_reply() does not advance through the xdr_buf
when setting up scatter/gather entries for SEND WR. It always calls
dma_map_xdr with xdr_off set to zero. When there's more than one
sge, dma_map_xdr() sets up the SEND sge's so they all point to the
xdr_buf's head.

The current Linux NFS/RDMA client always provides a reply chunk or
a write list when performing an NFS READ over RDMA. Therefore, it
does not exercise this particular case. The Linux server has never
had to use more than one extra sge for building RPC/RDMA replies
with a Linux client.

However, an NFS/RDMA client _is_ allowed to send small NFS READs
without setting up a write list or reply chunk. The NFS READ reply
fits entirely within the inline reply buffer in this case. This is
perhaps a more efficient way of performing NFS READs that the Linux
NFS/RDMA client may some day adopt.

Fixes: b432e6b3d9c1 ('svcrdma: Change DMA mapping logic to . . .')
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285
Signed-off-by: Chuck Lever 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

SUNRPC: Fix a memory leak in the backchannel code

2015-07-04T03:02:23+00:00

[ Upstream commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd ]

req->rq_private_buf isn't initialised when xprt_setup_backchannel calls
xprt_free_allocation.

Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
Cc: stable@vger.kernel.org
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

xprtrdma: Prevent infinite loop in rpcrdma_ep_create()

2015-06-28T17:39:21+00:00

[ Upstream commit 41f97028969e4c88efa5fcf58bc6125210413a6d ]

If a provider advertizes a zero max_fast_reg_page_list_len, FRWR
depth detection loops forever. Instead of just failing the mount,
try other memory registration modes.

Fixes: 0fc6c4e7bb28 ("xprtrdma: mind the device's max fast . . .")
Reported-by: Devesh Sharma 
Signed-off-by: Chuck Lever 
Tested-by: Devesh Sharma 
Tested-by: Meghana Cheripady 
Tested-by: Veeresh U. Kokatnur 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

xprtrdma: Take struct ib_device_attr off the stack

2015-06-28T17:39:21+00:00

[ Upstream commit 7bc7972cdd1f137552ca979caa11c8acbe119ae8 ]

Device attributes are large, and are used in more than one place.
Stash a copy in dynamically allocated memory.

Signed-off-by: Chuck Lever 
Reviewed-by: Steve Wise 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin

svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures

2015-06-10T17:42:36+00:00

[ Upstream commit 9507271d960a1911a51683888837d75c171cd91f ]

In an environment where the KDC is running Active Directory, the
exported composite name field returned in the context could be large
enough to span a page boundary.  Attaching a scratch buffer to the
decoding xdr_stream helps deal with those cases.

The case where we saw this was actually due to behavior that's been
fixed in newer gss-proxy versions, but we're fixing it here too.

Signed-off-by: Scott Mayhew 
Cc: stable@vger.kernel.org
Reviewed-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock

2015-03-14T19:37:27+00:00

commit 813b00d63f6ca1ed40a2f4f9c034d59bc424025e upstream.

Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock.
xprt_complete_bc_request() should do the same.

Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split . . .")
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin

sunrpc: fix braino in ->poll()

2015-03-14T19:37:27+00:00

commit 1711fd9addf214823b993468567cab1f8254fc51 upstream.

POLL_OUT isn't what callers of ->poll() are expecting to see; it's
actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
bit...

Signed-off-by: Al Viro 
Cc: Bruce Fields 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

SUNRPC: NULL utsname dereference on NFS umount during namespace cleanup

2015-03-06T22:52:58+00:00

commit 03a9a42a1a7e5b3e7919ddfacc1d1cc81882a955 upstream.

Fix an Oopsable condition when nsm_mon_unmon is called as part of the
namespace cleanup, which now apparently happens after the utsname
has been freed.

Link: http://lkml.kernel.org/r/20150125220604.090121ae@neptune.home
Reported-by: Bruno Prémont 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

rpc: fix xdr_truncate_encode to handle buffer ending on page boundary

2015-01-16T14:59:55+00:00

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