1. 14 Dec, 2020 3 commits
    • Chuck Lever's avatar
      xprtrdma: Fix XDRBUF_SPARSE_PAGES support · 15261b91
      Chuck Lever authored
      Olga K. observed that rpcrdma_marsh_req() allocates sparse pages
      only when it has determined that a Reply chunk is necessary. There
      are plenty of cases where no Reply chunk is needed, but the
      XDRBUF_SPARSE_PAGES flag is set. The result would be a crash in
      rpcrdma_inline_fixup() when it tries to copy parts of the received
      Reply into a missing page.
      
      To avoid crashing, handle sparse page allocation up front.
      
      Until XATTR support was added, this issue did not appear often
      because the only SPARSE_PAGES consumer always expected a reply large
      enough to always require a Reply chunk.
      Reported-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      15261b91
    • Frank van der Linden's avatar
      NFSv4.2: improve page handling for GETXATTR · a1f26739
      Frank van der Linden authored
      XDRBUF_SPARSE_PAGES can cause problems for the RDMA transport,
      and it's easy enough to allocate enough pages for the request
      up front, so do that.
      
      Also, since we've allocated the pages anyway, use the full
      page aligned length for the receive buffer. This will allow
      caching of valid replies that are too large for the caller,
      but that still fit in the allocated pages.
      Signed-off-by: default avatarFrank van der Linden <fllinden@amazon.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      a1f26739
    • Dan Aloni's avatar
      sunrpc: fix xs_read_xdr_buf for partial pages receive · ac9645c8
      Dan Aloni authored
      When receiving pages data, return value 'ret' when positive includes
      `buf->page_base`, so we should subtract that before it is used for
      changing `offset` and comparing against `want`.
      
      This was discovered on the very rare cases where the server returned a
      chunk of bytes that when added to the already received amount of bytes
      for the pages happened to match the current `recv.len`, for example
      on this case:
      
           buf->page_base : 258356
           actually received from socket: 1740
           ret : 260096
           want : 260096
      
      In this case neither of the two 'if ... goto out' trigger, and we
      continue to tail parsing.
      
      Worth to mention that the ensuing EMSGSIZE from the continued execution of
      `xs_read_xdr_buf` may be observed by an application due to 4 superfluous
      bytes being added to the pages data.
      
      Fixes: 277e4ab7 ("SUNRPC: Simplify TCP receive code by switching to using iterators")
      Signed-off-by: default avatarDan Aloni <dan@kernelim.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      ac9645c8
  2. 10 Dec, 2020 1 commit
  3. 02 Dec, 2020 36 commits