Skip to content

L
linux
Switch branch/tag
  1. 21 Oct, 2010 8 commits
    • J. Bruce Fields's avatar
      nfsd4: confirm only on succesful create_session · 86c3e16c
      J. Bruce Fields authored 
      Following rfc 5661, section 18.36.4: "If the session is not successfully
created, then no changes are made to any client records on the server."
We shouldn't be confirming or incrementing the sequence id in this case.
Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      86c3e16c
    • J. Bruce Fields's avatar
      nfsd4: make backchannel sequence number per-session · ac7c46f2
      J. Bruce Fields authored 
      Currently we don't deal well with a client that has multiple sessions
associated with it (even simultaneously, or serially over the lifetime
of the client).

In particular, we don't attempt to keep the backchannel running after
the original session diseappears.

We will fix that soon.

Once we do that, we need the slot sequence number to be per-session;
otherwise, for example, we cannot correctly handle a case like this:

	- All session 1 connections are lost.
	- The client creates session 2.  We use it for the backchannel
	  (since it's the only working choice).
	- The client gives us a new connection to use with session 1.
	- The client destroys session 2.

At this point our only choice is to go back to using session 1.  When we
do so we must use the sequence number that is next for session 1.  We
therefore need to maintain multiple sequence number streams.
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      ac7c46f2
    • J. Bruce Fields's avatar
      nfsd4: use client pointer to backchannel session · 90c8145b
      J. Bruce Fields authored 
      Instead of copying the sessionid, use the new cl_cb_session pointer,
which indicates which session we're using for the backchannel.
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      90c8145b
    • J. Bruce Fields's avatar
      nfsd4: move callback setup into session init code · edd76786
      J. Bruce Fields authored 
      The backchannel should  be associated with a session, it isn't really
global to the client.

We do, however, want a pointer global to the client which tracks which
session we're currently using for client-based callbacks.

This is a first step in that direction; for now, just reshuffling of
code with no significant change in behavior.
Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      edd76786
    • J. Bruce Fields's avatar
      nfsd4: don't cache seq_misordered replies · cd5b8144
      J. Bruce Fields authored 
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      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
  3. 19 Oct, 2010 17 commits
  5. 18 Oct, 2010 2 commits
  7. 12 Oct, 2010 2 commits
  9. 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
  11. 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
  13. 01 Oct, 2010 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7