1. 08 11月, 2014 1 次提交
    • J
      nfsd: convert nfs4_file searches to use RCU · 5b095e99
      Jeff Layton 提交于
      The global state_lock protects the file_hashtbl, and that has the
      potential to be a scalability bottleneck.
      
      Address this by making the file_hashtbl use RCU. Add a rcu_head to the
      nfs4_file and use that when freeing ones that have been hashed. In order
      to conserve space, we union the fi_rcu field with the fi_delegations
      list_head which must be clear by the time the last reference to the file
      is dropped.
      
      Convert find_file_locked to use RCU lookup primitives and not to require
      that the state_lock be held, and convert find_file to do a lockless
      lookup. Convert find_or_add_file to attempt a lockless lookup first, and
      then fall back to doing a locked search and insert if that fails to find
      anything.
      
      Also, minimize the number of times we need to calculate the hash value
      by passing it in as an argument to the search and insert functions, and
      optimize the order of arguments in nfsd4_init_file.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      5b095e99
  2. 24 10月, 2014 1 次提交
  3. 08 10月, 2014 1 次提交
  4. 02 10月, 2014 1 次提交
  5. 27 9月, 2014 4 次提交
  6. 18 9月, 2014 3 次提交
  7. 06 8月, 2014 2 次提交
  8. 05 8月, 2014 7 次提交
  9. 02 8月, 2014 1 次提交
  10. 01 8月, 2014 7 次提交
  11. 30 7月, 2014 1 次提交
  12. 24 7月, 2014 2 次提交
  13. 22 7月, 2014 1 次提交
  14. 17 7月, 2014 3 次提交
  15. 11 7月, 2014 4 次提交
    • J
      nfsd: make deny mode enforcement more efficient and close races in it · baeb4ff0
      Jeff Layton 提交于
      The current enforcement of deny modes is both inefficient and scattered
      across several places, which makes it hard to guarantee atomicity. The
      inefficiency is a problem now, and the lack of atomicity will mean races
      once the client_mutex is removed.
      
      First, we address the inefficiency. We have to track deny modes on a
      per-stateid basis to ensure that open downgrades are sane, but when the
      server goes to enforce them it has to walk the entire list of stateids
      and check against each one.
      
      Instead of doing that, maintain a per-nfs4_file deny mode. When a file
      is opened, we simply set any deny bits in that mode that were specified
      in the OPEN call. We can then use that unified deny mode to do a simple
      check to see whether there are any conflicts without needing to walk the
      entire stateid list.
      
      The only time we'll need to walk the entire list of stateids is when a
      stateid that has a deny mode on it is being released, or one is having
      its deny mode downgraded. In that case, we must walk the entire list and
      recalculate the fi_share_deny field. Since deny modes are pretty rare
      today, this should be very rare under normal workloads.
      
      To address the potential for races once the client_mutex is removed,
      protect fi_share_deny with the fi_lock. In nfs4_get_vfs_file, check to
      make sure that any deny mode we want to apply won't conflict with
      existing access. If that's ok, then have nfs4_file_get_access check that
      new access to the file won't conflict with existing deny modes.
      
      If that also passes, then get file access references, set the correct
      access and deny bits in the stateid, and update the fi_share_deny field.
      If opening the file or truncating it fails, then unwind the whole mess
      and return the appropriate error.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      baeb4ff0
    • J
      nfsd: shrink st_access_bmap and st_deny_bmap · c11c591f
      Jeff Layton 提交于
      We never use anything above bit #3, so an unsigned long for each is
      wasteful. Shrink them to a char each, and add some WARN_ON_ONCE calls if
      we try to set or clear bits that would go outside those sizes.
      
      Note too that because atomic bitops work on unsigned longs, we have to
      abandon their use here. That shouldn't be a problem though since we
      don't really care about the atomicity in this code anyway. Using them
      was just a convenient way to flip bits.
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c11c591f
    • T
      nfsd: Add locking to the nfs4_file->fi_fds[] array · de18643d
      Trond Myklebust 提交于
      Preparation for removal of the client_mutex, which currently protects
      this array. While we don't actually need the find_*_file_locked variants
      just yet, a later patch will. So go ahead and add them now to reduce
      future churn in this code.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      de18643d
    • T
      nfsd: Add fine grained protection for the nfs4_file->fi_stateids list · 1d31a253
      Trond Myklebust 提交于
      Access to this list is currently serialized by the client_mutex. Add
      finer grained locking around this list in preparation for its removal.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      1d31a253
  16. 10 7月, 2014 1 次提交