1. 11 Jan, 2011 1 commit
  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
      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
      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>
    • 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>
  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)
      This (C) case conflicts with (A) :
      CPU1 [A]                         CPU2 [C]
      <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() :
      bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock)
      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)
      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>
  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
  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
  16. 03 Dec, 2009 1 commit
    • Chuck Lever's avatar
      SUNRPC: Allow RPCs to fail quickly if the server is unreachable · 09a21c41
      Chuck Lever authored
      The kernel sometimes makes RPC calls to services that aren't running.
      Because the kernel's RPC client always assumes the hard retry semantic
      when reconnecting a connection-oriented RPC transport, the underlying
      reconnect logic takes a long while to time out, even though the remote
      may have responded immediately with ECONNREFUSED.
      In certain cases, like upcalls to our local rpcbind daemon, or for NFS
      mount requests, we'd like the kernel to fail immediately if the remote
      service isn't reachable.  This allows another transport to be tried
      immediately, or the pending request can be abandoned quickly.
      Introduce a per-request flag which controls how call_transmit_status()
      behaves when request transmission fails because the server cannot be
      We don't want soft connection semantics to apply to other errors.  The
      default case of the switch statement in call_transmit_status() no
      longer falls through; the fall through code is copied to the default
      case, and a "break;" is added.
      The transport's connection re-establishment timeout is also ignored for
      such requests.  We want the request to fail immediately, so the
      reconnect delay is skipped.  Additionally, we don't want a connect
      failure here to further increase the reconnect timeout value, since
      this request will not be retried.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
  17. 18 Nov, 2009 1 commit