1. 25 10月, 2016 1 次提交
  2. 27 9月, 2016 1 次提交
    • J
      nfsd: add a LRU list for blocked locks · 7919d0a2
      Jeff Layton 提交于
      It's possible for a client to call in on a lock that is blocked for a
      long time, but discontinue polling for it. A malicious client could
      even set a lock on a file, and then spam the server with failing lock
      requests from different lockowners that pile up in a DoS attack.
      
      Add the blocked lock structures to a per-net namespace LRU when hashing
      them, and timestamp them. If the lock request is not revisited after a
      lease period, we'll drop it under the assumption that the client is no
      longer interested.
      
      This also gives us a mechanism to clean up these objects at server
      shutdown time as well.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7919d0a2
  3. 24 11月, 2015 1 次提交
  4. 11 8月, 2015 1 次提交
  5. 06 8月, 2014 1 次提交
  6. 05 8月, 2014 1 次提交
    • J
      nfsd: protect clid and verifier generation with client_lock · 294ac32e
      Jeff Layton 提交于
      The clid counter is a global counter currently. Move it to be a per-net
      property so that it can be properly protected by the nn->client_lock
      instead of relying on the client_mutex.
      
      The verifier generator is also potentially racy if there are two
      simultaneous callers. Generate the verifier when we generate the clid
      value, so it's also created under the client_lock. With this, there's
      no need to keep two counters as they'd always be in sync anyway, so
      just use the clientid_counter for both.
      
      As Trond points out, what would be best is to eventually move this
      code to use IDR instead of the hash tables. That would also help ensure
      uniqueness, but that's probably best done as a separate project.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      294ac32e
  7. 01 8月, 2014 1 次提交
  8. 10 7月, 2014 1 次提交
  9. 09 7月, 2014 1 次提交
    • J
      nfsd: add a new /proc/fs/nfsd/max_connections file · 5b8db00b
      Jeff Layton 提交于
      Currently, the maximum number of connections that nfsd will allow
      is based on the number of threads spawned. While this is fine for a
      default, there really isn't a clear relationship between the two.
      
      The number of threads corresponds to the number of concurrent requests
      that we want to allow the server to process at any given time. The
      connection limit corresponds to the maximum number of clients that we
      want to allow the server to handle. These are two entirely different
      quantities.
      
      Break the dependency on increasing threads in order to allow for more
      connections, by adding a new per-net parameter that can be set to a
      non-zero value. The default is still to base it on the number of threads,
      so there should be no behavior change for anyone who doesn't use it.
      
      Cc: Trond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      5b8db00b
  10. 04 1月, 2014 1 次提交
  11. 05 4月, 2013 1 次提交
  12. 11 12月, 2012 4 次提交
  13. 03 12月, 2012 1 次提交
  14. 28 11月, 2012 5 次提交
  15. 15 11月, 2012 11 次提交
  16. 28 7月, 2012 3 次提交
  17. 12 4月, 2012 4 次提交
  18. 29 3月, 2012 1 次提交