1. 05 Aug, 2016 3 commits
    • Trond Myklebust's avatar
      NFSv4.2: LAYOUTSTATS may return NFS4ERR_ADMIN/DELEG_REVOKED · 206b3bb5
      Trond Myklebust authored
      We should handle those errors in the same way we handle the other
      stateid errors: by invalidating the faulty layout stateid.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      206b3bb5
    • NeilBrown's avatar
      SUNRPC: disable the use of IPv6 temporary addresses. · d88e4d82
      NeilBrown authored
      If the net.ipv6.conf.*.use_temp_addr sysctl is set to '2',
      then TCP connections over IPv6 will prefer a 'private' source
      address.
      These eventually expire and become invalid, typically after a week,
      but the time is configurable.
      
      When the local address becomes invalid the client will not be able to
      receive replies from the server.  Eventually the connection will timeout
      or break and a new connection will be established, but this can take
      half an hour (typically TCP connection break time).
      
      RFC 4941, which describes private IPv6 addresses, acknowledges that some
      applications might not work well with them and that the application may
      explicitly a request non-temporary (i.e. "public") address.
      
      I believe this is correct for SUNRPC clients.  Without this change, a
      client will occasionally experience a long delay if private addresses
      have been enabled.
      
      The privacy offered by private addresses is of little value for an NFS
      server which requires client authentication.
      
      For NFSv3 this will often not be a problem because idle connections are
      closed after 5 minutes.  For NFSv4 connections never go idle due to the
      period RENEW (or equivalent) request.
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      d88e4d82
    • Olga Kornievskaia's avatar
      SUNRPC: allow for upcalls for same uid but different gss service · 9130b8db
      Olga Kornievskaia authored
      It's possible to have simultaneous upcalls for the same UIDs but
      different GSS service. In that case, we need to allow for the
      upcall to gssd to proceed so that not the same context is used
      by two different GSS services. Some servers lock the use of context
      to the GSS service.
      Signed-off-by: default avatarOlga Kornievskaia <kolga@netapp.com>
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      9130b8db
  2. 02 Aug, 2016 1 commit
  3. 01 Aug, 2016 1 commit
  4. 28 Jul, 2016 1 commit
  5. 26 Jul, 2016 1 commit
  6. 24 Jul, 2016 22 commits
  7. 22 Jul, 2016 2 commits
  8. 21 Jul, 2016 1 commit
  9. 19 Jul, 2016 8 commits