1. 08 Jun, 2018 1 commit
  2. 06 Jun, 2018 2 commits
    • Chuck Lever's avatar
      NFSv4.0: Remove transport protocol name from non-UCS client ID · 025bb9f8
      Chuck Lever authored
      Commit 69dd716c ("NFSv4: Add socket proto argument to
      setclientid") (2007) added the transport protocol name to the client
      ID string, but the patch description doesn't explain why this was
      necessary.
      
      At that time, the only transport protocol name that would have been
      used is "tcp" (for both IPv4 and IPv6), resulting in no additional
      distinctiveness of the client ID string.
      
      Since there is one client instance, the server should recognize it's
      state whether the client is connecting via TCP or RDMA. Same client,
      same lease.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      025bb9f8
    • Chuck Lever's avatar
      NFSv4.0: Remove cl_ipaddr from non-UCS client ID · 848a4eb2
      Chuck Lever authored
      It is possible for two distinct clients to have the same cl_ipaddr:
      
       - if the client admin disables callback with clientaddr=0.0.0.0 on
         more than one client
      
       - if two clients behind separate NATs use the same private subnet
         number
      
       - if the client admin specifies the same address via clientaddr=
         mount option (pointing the server at the same NAT box, for
         example)
      
      Because of the way the Linux NFSv4.0 client constructs its client
      ID string by default, such clients could interfere with each others'
      lease state when mounting the same server:
      
      	scnprintf(str, len, "Linux NFSv4.0 %s/%s %s",
      		clp->cl_ipaddr,
      		rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_ADDR),
      		rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_PROTO));
      
      cl_ipaddr is set to the value of the clientaddr= mount option. Two
      clients whose addresses are 192.168.3.77 that mount the same server
      (whose public IP address is, say, 3.4.5.6) would both generate the
      same client ID string when sending a SETCLIENTID:
      
        Linux NFSv4.0 192.168.3.77/3.4.5.6 tcp
      
      and thus the server would not be able to distinguish the clients'
      leases. If both clients are using AUTH_SYS when sending SETCLIENTID
      then the server could possibly permit the two clients to interfere
      with or purge each others' leases.
      
      To better ensure that Linux's NFSv4.0 client ID strings are distinct
      in these cases, remove cl_ipaddr from the client ID string and
      replace it with something more likely to be unique. Note that the
      replacement looks a lot like the uniform client ID string.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      848a4eb2
  3. 05 Jun, 2018 1 commit
  4. 04 Jun, 2018 12 commits
  5. 01 Jun, 2018 5 commits
  6. 31 May, 2018 19 commits