1. 11 Jan, 2011 3 commits
    • J. Bruce Fields's avatar
      rpc: allow xprt_class->setup to return a preexisting xprt · f0418aa4
      J. Bruce Fields authored
      
      
      This allows us to reuse the xprt associated with a server connection if
      one has already been set up.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      f0418aa4
    • J. Bruce Fields's avatar
      rpc: keep backchannel xprt as long as server connection · 99de8ea9
      J. Bruce Fields authored
      
      
      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: default avatarJ. Bruce Fields <bfields@redhat.com>
      99de8ea9
    • J. Bruce Fields's avatar
      rpc: move sk_bc_xprt to svc_xprt · d75faea3
      J. Bruce Fields authored
      
      
      This seems obviously transport-level information even if it's currently
      used only by the server socket code.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      d75faea3
  2. 21 Oct, 2010 2 commits
    • 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
  3. 19 Oct, 2010 14 commits
  4. 01 Oct, 2010 4 commits
  5. 24 Sep, 2010 1 commit
    • Eric Dumazet's avatar
      net: fix a lockdep splat · f064af1e
      Eric Dumazet authored
      
      
      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: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Tested-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      CC: Jarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f064af1e
  6. 11 Aug, 2010 1 commit
    • Rusty Russell's avatar
      param: use ops in struct kernel_param, rather than get and set fns directly · 9bbb9e5a
      Rusty Russell authored
      
      
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarPhil 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
  7. 10 Aug, 2010 1 commit
  8. 22 Jun, 2010 1 commit
  9. 26 May, 2010 1 commit
  10. 18 May, 2010 1 commit
  11. 14 May, 2010 5 commits
  12. 22 Mar, 2010 1 commit
  13. 08 Mar, 2010 3 commits
  14. 02 Mar, 2010 1 commit
  15. 10 Feb, 2010 1 commit