1. 31 Aug, 2015 5 commits
  2. 13 Aug, 2015 7 commits
  3. 10 Aug, 2015 22 commits
  4. 31 Jul, 2015 1 commit
    • Jeff Layton's avatar
      nfsd: do nfs4_check_fh in nfs4_check_file instead of nfs4_check_olstateid · 8fcd461d
      Jeff Layton authored
      Currently, preprocess_stateid_op calls nfs4_check_olstateid which
      verifies that the open stateid corresponds to the current filehandle in the
      call by calling nfs4_check_fh.
      
      If the stateid is a NFS4_DELEG_STID however, then no such check is done.
      This could cause incorrect enforcement of permissions, because the
      nfsd_permission() call in nfs4_check_file uses current the current
      filehandle, but any subsequent IO operation will use the file descriptor
      in the stateid.
      
      Move the call to nfs4_check_fh into nfs4_check_file instead so that it
      can be done for all stateid types.
      Signed-off-by: default avatarJeff Layton <jeff.layton@primarydata.com>
      Cc: stable@vger.kernel.org
      [bfields: moved fh check to avoid NULL deref in special stateid case]
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      8fcd461d
  5. 20 Jul, 2015 5 commits
    • Chuck Lever's avatar
      svcrdma: Remove svc_rdma_fastreg() · 31193fe5
      Chuck Lever authored
      Commit 0bf48289 ("svcrdma: refactor marshalling logic") removed
      the last call site for svc_rdma_fastreg().
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      31193fe5
    • Chuck Lever's avatar
      svcrdma: Clean up svc_rdma_get_reply_array() · 10dc4512
      Chuck Lever authored
      Kernel coding conventions frown upon having large nontrivial
      functions in header files, and the preference these days is to
      allow the compiler to make inlining decisions if possible.
      
      As these functions are re-homed into a .c file, be sure that
      comparisons with fields in struct rpcrdma_msg are with be32
      constants.
      
      This is a refactoring change; no behavior change is intended.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      10dc4512
    • Chuck Lever's avatar
      svcrdma: Fix send_reply() scatter/gather set-up · 9d11b51c
      Chuck Lever authored
      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: b432e6b3 ('svcrdma: Change DMA mapping logic to . . .')
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      9d11b51c
    • Shirley Ma's avatar
      NFS/RDMA Release resources in svcrdma when device is removed · ff79c74d
      Shirley Ma authored
      When removing underlying RDMA device, the rmmod will hang forever if there
      are any outstanding NFS/RDMA client mounts. The outstanding NFS/RDMA counts
      could also prevent the server from shutting down. Further debugging shows
      that the existing connections are not teared down and resource are not
      released when receiving RDMA_CM_EVENT_DEVICE_REMOVAL event. It seems the
      original code missing svc_xprt_put() in RDMA_CM_EVENT_REMOVAL event handler
      thus svc_xprt_free is never invoked to release the existing connection
      resources.
      
      The patch has been passed removing, adding device back and forth without
      stopping NFS/RDMA service. This will also allow a device to be unplugged
      and swapped out without shutting down NFS service.
      
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=252Signed-off-by: default avatarShirley Ma <shirley.ma@oracle.com>
      Reviewed-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      ff79c74d
    • Kinglong Mee's avatar
      7b8f4586