1. 21 Oct, 2010 4 commits
    • J. Bruce Fields's avatar
      cd5b8144
    • Chuck Lever's avatar
      SUNRPC: Properly initialize sock_xprt.srcaddr in all cases · 92476850
      Chuck Lever authored
      The source address field in the transport's sock_xprt is initialized
      ONLY IF the RPC application passed a pointer to a source address
      during the call to rpc_create().  However, xs_bind() subsequently uses
      the value of this field without regard to whether the source address
      was initialized during transport creation or not.
      
      So far we've been lucky: the uninitialized value of this field is
      zeroes.  xs_bind(), until recently, used only the sin[6]_addr field in
      this sockaddr, and all zeroes is a valid value for this: it means
      ANYADDR.  This is a happy coincidence.
      
      However, xs_bind() now wants to use the sa_family field as well, and
      expects it to be initialized to something other than zero.
      
      Therefore, the source address sockaddr field should be fully
      initialized at transport create time in _every_ case, not just when
      the RPC application wants to use a specific bind address.
      
      Bruce added a workaround for this missing initialization by adjusting
      commit 6bc9638a, but the "right" way to do this is to ensure that the
      source address sockaddr is always correctly initialized from the
      get-go.
      
      This patch doesn't introduce a behavior change.  It's simply a
      clean-up of Bruce's fix, to prevent future problems of this kind.  It
      may look like overkill, but
      
        a) it clearly documents the default initial value of this field,
      
        b) it doesn't assume that the sockaddr_storage memory is first
           initialized to any particular value, and
      
        c) it will fail verbosely if some unknown address family is passed
           in
      
      Originally introduced by commit d3bc9a1d.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      92476850
    • Chuck Lever's avatar
      SUNRPC: Use conventional switch statement when reclassifying sockets · 4232e863
      Chuck Lever authored
      Clean up.
      
      Defensive coding: If "family" is ever something that is neither
      AF_INET nor AF_INET6, xs_reclassify_socket6() is not the appropriate
      default action.  Choose to do nothing in that case.
      
      Introduced by commit 6bc9638a.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      4232e863
    • Tejun Heo's avatar
      sunrpc/xprtrdma: clean up workqueue usage · a25e758c
      Tejun Heo authored
      * Create and use svc_rdma_wq instead of using the system workqueue and
        flush_scheduled_work().  This workqueue is necessary to serve as
        flushing domain for rdma->sc_work which is used to destroy itself
        and thus can't be flushed explicitly.
      
      * Replace cancel_delayed_work() + flush_scheduled_work() with
        cancel_delayed_work_sync().
      
      * Implement synchronous connect in xprt_rdma_connect() using
        flush_delayed_work() on the rdma_connect work instead of using
        flush_scheduled_work().
      
      This is to prepare for the deprecation and removal of
      flush_scheduled_work().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      a25e758c
  2. 19 Oct, 2010 17 commits
  3. 18 Oct, 2010 2 commits
  4. 12 Oct, 2010 2 commits
  5. 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
  6. 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
  7. 01 Oct, 2010 12 commits