1. 03 Oct, 2008 3 commits
    • J. Bruce Fields's avatar
      lockd: reject reclaims outside the grace period · d22b1cff
      J. Bruce Fields authored
      The current lockd does not reject reclaims that arrive outside of the
      grace period.
      
      Accepting a reclaim means promising to the client that no conflicting
      locks were granted since last it held the lock.  We can meet that
      promise if we assume the only lockers are nfs clients, and that they are
      sufficiently well-behaved to reclaim only locks that they held before,
      and that only reclaim locks have been permitted so far.  Once we leave
      the grace period (and start permitting non-reclaims), we can no longer
      keep that promise.  So we must start rejecting reclaims at that point.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      d22b1cff
    • J. Bruce Fields's avatar
      lockd: move grace period checks to common code · b2b50289
      J. Bruce Fields authored
      Do all the grace period checks in svclock.c.  This simplifies the code a
      bit, and will ease some later changes.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      b2b50289
    • J. Bruce Fields's avatar
      nfsd: common grace period control · af558e33
      J. Bruce Fields authored
      Rewrite grace period code to unify management of grace period across
      lockd and nfsd.  The current code has lockd and nfsd cooperate to
      compute a grace period which is satisfactory to them both, and then
      individually enforce it.  This creates a slight race condition, since
      the enforcement is not coordinated.  It's also more complicated than
      necessary.
      
      Here instead we have lockd and nfsd each inform common code when they
      enter the grace period, and when they're ready to leave the grace
      period, and allow normal locking only after both of them are ready to
      leave.
      
      We also expect the locks_start_grace()/locks_end_grace() interface here
      to be simpler to build on for future cluster/high-availability work,
      which may require (for example) putting individual filesystems into
      grace, or enforcing grace periods across multiple cluster nodes.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      af558e33
  2. 29 Sep, 2008 36 commits
  3. 21 Sep, 2008 1 commit