1. 05 Oct, 2022 2 commits
    • Jeff Layton's avatar
      nfsd: rework hashtable handling in nfsd_do_file_acquire · 243a5263
      Jeff Layton authored
      nfsd_file is RCU-freed, so we need to hold the rcu_read_lock long enough
      to get a reference after finding it in the hash. Take the
      rcu_read_lock() and call rhashtable_lookup directly.
      
      Switch to using rhashtable_lookup_insert_key as well, and use the usual
      retry mechanism if we hit an -EEXIST. Rename the "retry" bool to
      open_retry, and eliminiate the insert_err goto target.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      243a5263
    • Jeff Layton's avatar
      nfsd: fix nfsd_file_unhash_and_dispose · 8d0d254b
      Jeff Layton authored
      nfsd_file_unhash_and_dispose() is called for two reasons:
      
      We're either shutting down and purging the filecache, or we've gotten a
      notification about a file delete, so we want to go ahead and unhash it
      so that it'll get cleaned up when we close.
      
      We're either walking the hashtable or doing a lookup in it and we
      don't take a reference in either case. What we want to do in both cases
      is to try and unhash the object and put it on the dispose list if that
      was successful. If it's no longer hashed, then we don't want to touch
      it, with the assumption being that something else is already cleaning
      up the sentinel reference.
      
      Instead of trying to selectively decrement the refcount in this
      function, just unhash it, and if that was successful, move it to the
      dispose list. Then, the disposal routine will just clean that up as
      usual.
      
      Also, just make this a void function, drop the WARN_ON_ONCE, and the
      comments about deadlocking since the nature of the purported deadlock
      is no longer clear.
      Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      8d0d254b
  2. 26 Sep, 2022 38 commits