1. 09 Jul, 2019 1 commit
  2. 08 Jul, 2019 1 commit
  3. 04 Jul, 2019 1 commit
    • J. Bruce Fields's avatar
      nfsd: decode implementation id · 79123444
      J. Bruce Fields authored
      Decode the implementation ID and display in nfsd/clients/#/info.  It may
      be help identify the client.  It won't be used otherwise.
      
      (When this went into the protocol, I thought the implementation ID would
      be a slippery slope towards implementation-specific workarounds as with
      the http user-agent.  But I guess I was wrong, the risk seems pretty low
      now.)
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      79123444
  4. 03 Jul, 2019 30 commits
  5. 19 Jun, 2019 1 commit
    • Chuck Lever's avatar
      svcrdma: Ignore source port when computing DRC hash · 1e091c3b
      Chuck Lever authored
      The DRC appears to be effectively empty after an RPC/RDMA transport
      reconnect. The problem is that each connection uses a different
      source port, which defeats the DRC hash.
      
      Clients always have to disconnect before they send retransmissions
      to reset the connection's credit accounting, thus every retransmit
      on NFS/RDMA will miss the DRC.
      
      An NFS/RDMA client's IP source port is meaningless for RDMA
      transports. The transport layer typically sets the source port value
      on the connection to a random ephemeral port. The server already
      ignores it for the "secure port" check. See commit 16e4d93f
      ("NFSD: Ignore client's source port on RDMA transports").
      
      The Linux NFS server's DRC resolves XID collisions from the same
      source IP address by using the checksum of the first 200 bytes of
      the RPC call header.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org # v4.14+
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      1e091c3b
  6. 31 May, 2019 1 commit
  7. 26 May, 2019 5 commits