1. 19 Oct, 2010 9 commits
  2. 18 Oct, 2010 2 commits
  3. 12 Oct, 2010 2 commits
  4. 11 Oct, 2010 2 commits
    • NeilBrown's avatar
      sunrpc/cache: centralise handling of size limit on deferred list. · e33534d5
      NeilBrown authored
      We limit the number of 'defer' requests to DFR_MAX.
      
      The imposition of this limit is spread about a bit - sometime we don't
      add new things to the list, sometimes we remove old things.
      
      Also it is currently applied to requests which we are 'waiting' for
      rather than 'deferring'.  This doesn't seem ideal as 'waiting'
      requests are naturally limited by the number of threads.
      
      So gather the DFR_MAX handling code to one place and only apply it to
      requests that are actually being deferred.
      
      This means that not all 'cache_deferred_req' structures go on the
      'cache_defer_list, so we need to be careful when adding and removing
      things.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      e33534d5
    • NeilBrown's avatar
      sunrpc: Simplify cache_defer_req and related functions. · d29068c4
      NeilBrown authored
      The return value from cache_defer_req is somewhat confusing.
      Various different error codes are returned, but the single caller is
      only interested in success or failure.
      
      In fact it can measure this success or failure itself by checking
      CACHE_PENDING, which makes the point of the code more explicit.
      
      So change cache_defer_req to return 'void' and test CACHE_PENDING
      after it completes, to see if the request was actually deferred or
      not.
      
      Similarly setup_deferral and cache_wait_req don't need a return value,
      so make them void and remove some code.
      
      The call to cache_revisit_request (to guard against a race) is only
      needed for the second call to setup_deferral, so move it out of
      setup_deferral to after that second call.  With the first call the
      race is handled differently (by explicitly calling
      'wait_for_completion').
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d29068c4
  5. 02 Oct, 2010 1 commit
    • J. Bruce Fields's avatar
      nfsd4: return expired on unfound stateid's · 33515142
      J. Bruce Fields authored
      Commit 78155ed7 "nfsd4: distinguish
      expired from stale stateids" attempted to distinguish expired and stale
      stateid's using time information that may not have been completely
      reliable, so I reverted it.
      
      That was throwing out the baby with the bathwater; we still do want to
      return expired, but let's do that using the simpler approach of just
      assuming any stateid is expired if it looks like it was given out by the
      current server instance, but we can't find it any more.
      
      This may help clients that are recovering from network partitions.
      Reported-by: default avatarBian Naimeng <biannm@cn.fujitsu.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      33515142
  6. 01 Oct, 2010 24 commits