1. 28 5月, 2011 3 次提交
    • C
      SUNRPC: Support for RPC over AF_LOCAL transports · 176e21ee
      Chuck Lever 提交于
      TI-RPC introduces the capability of performing RPC over AF_LOCAL
      sockets.  It uses this mainly for registering and unregistering
      local RPC services securely with the local rpcbind, but we could
      also conceivably use it as a generic upcall mechanism.
      
      This patch provides a client-side only implementation for the moment.
      We might also consider a server-side implementation to provide
      AF_LOCAL access to NLM (for statd downcalls, and such like).
      
      Autobinding is not supported on kernel AF_LOCAL transports at this
      time.  Kernel ULPs must specify the pathname of the remote endpoint
      when an AF_LOCAL transport is created.  rpcbind supports registering
      services available via AF_LOCAL, so the kernel could handle it with
      some adjustment to ->rpcbind and ->set_port.  But we don't need this
      feature for doing upcalls via well-known named sockets.
      
      This has not been tested with ULPs that move a substantial amount of
      data.  Thus, I can't attest to how robust the write_space and
      congestion management logic is.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      176e21ee
    • C
      SUNRPC: Rename xs_encode_tcp_fragment_header() · 61677eee
      Chuck Lever 提交于
      Clean up: Use a more generic name for xs_encode_tcp_fragment_header();
      it's appropriate to use for all stream transport types.  We're about
      to add new stream transport.
      
      Also, move it to a place where it is more easily shared amongst the
      various send_request methods.  And finally, replace the "htonl" macro
      invocation with its modern equivalent.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      61677eee
    • T
      SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback... · fe19a96b
      Trond Myklebust 提交于
      The TCP connection state code depends on the state_change() callback
      being called when the SYN_SENT state is set. However the networking layer
      doesn't actually call us back in that case.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      fe19a96b
  2. 31 3月, 2011 1 次提交
  3. 23 3月, 2011 1 次提交
  4. 11 3月, 2011 1 次提交
  5. 12 1月, 2011 3 次提交
    • J
      rpc: allow xprt_class->setup to return a preexisting xprt · f0418aa4
      J. Bruce Fields 提交于
      This allows us to reuse the xprt associated with a server connection if
      one has already been set up.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f0418aa4
    • J
      rpc: keep backchannel xprt as long as server connection · 99de8ea9
      J. Bruce Fields 提交于
      Multiple backchannels can share the same tcp connection; from rfc 5661 section
      2.10.3.1:
      
      	A connection's association with a session is not exclusive.  A
      	connection associated with the channel(s) of one session may be
      	simultaneously associated with the channel(s) of other sessions
      	including sessions associated with other client IDs.
      
      However, multiple backchannels share a connection, they must all share
      the same xid stream (hence the same rpc_xprt); the only way we have to
      match replies with calls at the rpc layer is using the xid.
      
      So, keep the rpc_xprt around as long as the connection lasts, in case
      we're asked to use the connection as a backchannel again.
      
      Requests to create new backchannel clients over a given server
      connection should results in creating new clients that reuse the
      existing rpc_xprt.
      
      But to start, just reject attempts to associate multiple rpc_xprt's with
      the same underlying bc_xprt.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      99de8ea9
    • J
      rpc: move sk_bc_xprt to svc_xprt · d75faea3
      J. Bruce Fields 提交于
      This seems obviously transport-level information even if it's currently
      used only by the server socket code.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      d75faea3
  6. 15 12月, 2010 1 次提交
    • T
      workqueue: convert cancel_rearming_delayed_work[queue]() users to cancel_delayed_work_sync() · afe2c511
      Tejun Heo 提交于
      cancel_rearming_delayed_work[queue]() has been superceded by
      cancel_delayed_work_sync() quite some time ago.  Convert all the
      in-kernel users.  The conversions are completely equivalent and
      trivial.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: N"David S. Miller" <davem@davemloft.net>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: netdev@vger.kernel.org
      Cc: Anton Vorontsov <cbou@mail.ru>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Alex Elder <aelder@sgi.com>
      Cc: xfs-masters@oss.sgi.com
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: netfilter-devel@vger.kernel.org
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: linux-nfs@vger.kernel.org
      afe2c511
  7. 21 10月, 2010 2 次提交
    • C
      SUNRPC: Properly initialize sock_xprt.srcaddr in all cases · 92476850
      Chuck Lever 提交于
      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: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      92476850
    • C
      SUNRPC: Use conventional switch statement when reclassifying sockets · 4232e863
      Chuck Lever 提交于
      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: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      4232e863
  8. 19 10月, 2010 14 次提交
  9. 02 10月, 2010 4 次提交
  10. 25 9月, 2010 1 次提交
    • E
      net: fix a lockdep splat · f064af1e
      Eric Dumazet 提交于
      We have for each socket :
      
      One spinlock (sk_slock.slock)
      One rwlock (sk_callback_lock)
      
      Possible scenarios are :
      
      (A) (this is used in net/sunrpc/xprtsock.c)
      read_lock(&sk->sk_callback_lock) (without blocking BH)
      <BH>
      spin_lock(&sk->sk_slock.slock);
      ...
      read_lock(&sk->sk_callback_lock);
      ...
      
      (B)
      write_lock_bh(&sk->sk_callback_lock)
      stuff
      write_unlock_bh(&sk->sk_callback_lock)
      
      (C)
      spin_lock_bh(&sk->sk_slock)
      ...
      write_lock_bh(&sk->sk_callback_lock)
      stuff
      write_unlock_bh(&sk->sk_callback_lock)
      spin_unlock_bh(&sk->sk_slock)
      
      This (C) case conflicts with (A) :
      
      CPU1 [A]                         CPU2 [C]
      read_lock(callback_lock)
      <BH>                             spin_lock_bh(slock)
      <wait to spin_lock(slock)>
                                       <wait to write_lock_bh(callback_lock)>
      
      We have one problematic (C) use case in inet_csk_listen_stop() :
      
      local_bh_disable();
      bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock)
      WARN_ON(sock_owned_by_user(child));
      ...
      sock_orphan(child); // write_lock_bh(&sk->sk_callback_lock)
      
      lockdep is not happy with this, as reported by Tetsuo Handa
      
      It seems only way to deal with this is to use read_lock_bh(callbacklock)
      everywhere.
      
      Thanks to Jarek for pointing a bug in my first attempt and suggesting
      this solution.
      Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Jarek Poplawski <jarkao2@gmail.com>
      Tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f064af1e
  11. 11 8月, 2010 1 次提交
    • R
      param: use ops in struct kernel_param, rather than get and set fns directly · 9bbb9e5a
      Rusty Russell 提交于
      This is more kernel-ish, saves some space, and also allows us to
      expand the ops without breaking all the callers who are happy for the
      new members to be NULL.
      
      The few places which defined their own param types are changed to the
      new scheme (more which crept in recently fixed in following patches).
      
      Since we're touching them anyway, we change get() and set() to take a
      const struct kernel_param (which they really are).  This causes some
      harmless warnings until we fix them (in following patches).
      
      To reduce churn, module_param_call creates the ops struct so the callers
      don't have to change (and casts the functions to reduce warnings).
      The modern version which takes an ops struct is called module_param_cb.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Tested-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ville Syrjala <syrjala@sci.fi>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Alessandro Rubini <rubini@ipvvis.unipv.it>
      Cc: Michal Januszewski <spock@gentoo.org>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-input@vger.kernel.org
      Cc: linux-fbdev-devel@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: netdev@vger.kernel.org
      9bbb9e5a
  12. 10 8月, 2010 1 次提交
  13. 23 6月, 2010 1 次提交
  14. 26 5月, 2010 1 次提交
  15. 18 5月, 2010 1 次提交
  16. 15 5月, 2010 4 次提交