An error occurred fetching the project authors.
  1. 26 Aug, 2021 2 commits
    • J. Bruce Fields's avatar
      nfs: don't allow reexport reclaims · bb0a55bb
      J. Bruce Fields authored
      In the reexport case, nfsd is currently passing along locks with the
      reclaim bit set.  The client sends a new lock request, which is granted
      if there's currently no conflict--even if it's possible a conflicting
      lock could have been briefly held in the interim.
      
      We don't currently have any way to safely grant reclaim, so for now
      let's just deny them all.
      
      I'm doing this by passing the reclaim bit to nfs and letting it fail the
      call, with the idea that eventually the client might be able to do
      something more forgiving here.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      bb0a55bb
    • J. Bruce Fields's avatar
      nfs: don't atempt blocking locks on nfs reexports · f657f8ee
      J. Bruce Fields authored
      NFS implements blocking locks by blocking inside its lock method.  In
      the reexport case, this blocks the nfs server thread, which could lead
      to deadlocks since an nfs server thread might be required to unlock the
      conflicting lock.  It also causes a crash, since the nfs server thread
      assumes it can free the lock when its lm_notify lock callback is called.
      
      Ideal would be to make the nfs lock method return without blocking in
      this case, but for now it works just not to attempt blocking locks.  The
      difference is just that the original client will have to poll (as it
      does in the v4.0 case) instead of getting a callback when the lock's
      available.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      f657f8ee
  2. 17 Aug, 2021 1 commit
  3. 07 Jul, 2021 3 commits
  4. 01 Jul, 2021 1 commit
  5. 25 May, 2021 1 commit
    • Dai Ngo's avatar
      NFSD: delay unmount source's export after inter-server copy completed. · f4e44b39
      Dai Ngo authored
      Currently the source's export is mounted and unmounted on every
      inter-server copy operation. This patch is an enhancement to delay
      the unmount of the source export for a certain period of time to
      eliminate the mount and unmount overhead on subsequent copy operations.
      
      After a copy operation completes, a work entry is added to the
      delayed unmount list with an expiration time. This list is serviced
      by the laundromat thread to unmount the export of the expired entries.
      Each time the export is being used again, its expiration time is
      extended and the entry is re-inserted to the tail of the list.
      
      The unmount task and the mount operation of the copy request are
      synced to make sure the export is not unmounted while it's being
      used.
      Signed-off-by: default avatarDai Ngo <dai.ngo@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      f4e44b39
  6. 18 May, 2021 12 commits
  7. 20 Apr, 2021 1 commit
  8. 19 Apr, 2021 4 commits
  9. 16 Apr, 2021 1 commit
    • J. Bruce Fields's avatar
      nfsd: ensure new clients break delegations · 217fd6f6
      J. Bruce Fields authored
      If nfsd already has an open file that it plans to use for IO from
      another, it may not need to do another vfs open, but it still may need
      to break any delegations in case the existing opens are for another
      client.
      
      Symptoms are that we may incorrectly fail to break a delegation on a
      write open from a different client, when the delegation-holding client
      already has a write open.
      
      Fixes: 28df3d15 ("nfsd: clients don't need to break their own delegations")
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      217fd6f6
  10. 15 Apr, 2021 1 commit
  11. 22 Mar, 2021 4 commits
  12. 09 Mar, 2021 2 commits
  13. 06 Mar, 2021 1 commit
  14. 28 Jan, 2021 3 commits
  15. 25 Jan, 2021 3 commits