1. 06 2月, 2016 1 次提交
  2. 07 1月, 2016 1 次提交
    • T
      SUNRPC: Fixup socket wait for memory · 13331a55
      Trond Myklebust 提交于
      We're seeing hangs in the NFS client code, with loops of the form:
      
       RPC: 30317 xmit incomplete (267368 left of 524448)
       RPC: 30317 call_status (status -11)
       RPC: 30317 call_transmit (status 0)
       RPC: 30317 xprt_prepare_transmit
       RPC: 30317 xprt_transmit(524448)
       RPC:       xs_tcp_send_request(267368) = -11
       RPC: 30317 xmit incomplete (267368 left of 524448)
       RPC: 30317 call_status (status -11)
       RPC: 30317 call_transmit (status 0)
       RPC: 30317 xprt_prepare_transmit
       RPC: 30317 xprt_transmit(524448)
      
      Turns out commit ceb5d58b ("net: fix sock_wake_async() rcu protection")
      moved SOCKWQ_ASYNC_NOSPACE out of sock->flags and into sk->sk_wq->flags,
      however it never tried to fix up the code in net/sunrpc.
      
      The new idiom is to use the flags in the RCU protected struct socket_wq.
      While we're at it, clear out the now redundant places where we set/clear
      SOCKWQ_ASYNC_NOSPACE and SOCK_NOSPACE. In principle, sk_stream_wait_memory()
      is supposed to set these for us, so we only need to clear them in the
      particular case of our ->write_space() callback.
      
      Fixes: ceb5d58b ("net: fix sock_wake_async() rcu protection")
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: stable@vger.kernel.org # 4.4
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      13331a55
  3. 28 12月, 2015 1 次提交
  4. 02 12月, 2015 1 次提交
    • E
      net: rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA · 9cd3e072
      Eric Dumazet 提交于
      This patch is a cleanup to make following patch easier to
      review.
      
      Goal is to move SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA
      from (struct socket)->flags to a (struct socket_wq)->flags
      to benefit from RCU protection in sock_wake_async()
      
      To ease backports, we rename both constants.
      
      Two new helpers, sk_set_bit(int nr, struct sock *sk)
      and sk_clear_bit(int net, struct sock *sk) are added so that
      following patch can change their implementation.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cd3e072
  5. 04 11月, 2015 1 次提交
  6. 03 11月, 2015 2 次提交
  7. 24 10月, 2015 1 次提交
  8. 08 10月, 2015 5 次提交
  9. 20 9月, 2015 1 次提交
  10. 18 9月, 2015 2 次提交
  11. 30 8月, 2015 2 次提交
  12. 20 8月, 2015 1 次提交
  13. 18 8月, 2015 1 次提交
    • T
      SUNRPC: Fix a thinko in xs_connect() · 99b1a4c3
      Trond Myklebust 提交于
      It is rather pointless to test the value of transport->inet after
      calling xs_reset_transport(), since it will always be zero, and
      so we will never see any exponential back off behaviour.
      Also don't force early connections for SOFTCONN tasks. If the server
      disconnects us, we should respect the exponential backoff.
      
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      99b1a4c3
  14. 28 7月, 2015 1 次提交
  15. 27 7月, 2015 1 次提交
    • N
      sunrpc: translate -EAGAIN to -ENOBUFS when socket is writable. · 743c69e7
      NeilBrown 提交于
      The networking layer does not reliably report the distinction between
      a non-block write failing because:
       1/ the queue is too full already and
       2/ a memory allocation attempt failed.
      
      The distinction is important because in the first case it is
      appropriate to retry as soon as the socket reports that it is
      writable, and in the second case a small delay is required as the
      socket will most likely report as writable but kmalloc could still
      fail.
      
      sk_stream_wait_memory() exhibits this distinction nicely, setting
      'vm_wait' if a small wait is needed.  However in the non-blocking case
      it always returns -EAGAIN no matter the cause of the failure.  This
      -EAGAIN call get all the way to sunrpc.
      
      The sunrpc layer expects EAGAIN to indicate the first cause, and
      ENOBUFS to indicate the second.  Various documentation suggests that
      this is not unreasonable, but does not guarantee the desired error
      codes.
      
      The result of getting -EAGAIN when -ENOBUFS is expected is that the
      send is tried again in a tight loop and soft lockups are reported.
      
      so: add tests after calls to xs_sendpages() to translate -EAGAIN into
      -ENOBUFS if the socket is writable.  This cannot happen inside
      xs_sendpages() as the test for "is socket writable" is different
      between TCP and UDP.
      
      With this change, the tight loop retrying xs_sendpages() becomes a
      loop which only retries every 250ms, and so will not trigger a
      soft-lockup warning.
      
      It is possible that the write did fail because the queue was too full
      and by the time xs_sendpages() completed, the queue was writable
      again.  In this case an extra 250ms delay is inserted that isn't
      really needed.  This circumstance suggests a degree of congestion so a
      delay is not necessarily a bad thing, and it can only cause a single
      250ms delay, not a series of them.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      743c69e7
  16. 03 7月, 2015 1 次提交
  17. 21 6月, 2015 1 次提交
  18. 20 6月, 2015 1 次提交
  19. 11 6月, 2015 6 次提交
  20. 02 6月, 2015 1 次提交
  21. 28 5月, 2015 1 次提交
    • L
      kernel/params: constify struct kernel_param_ops uses · 9c27847d
      Luis R. Rodriguez 提交于
      Most code already uses consts for the struct kernel_param_ops,
      sweep the kernel for the last offending stragglers. Other than
      include/linux/moduleparam.h and kernel/params.c all other changes
      were generated with the following Coccinelle SmPL patch. Merge
      conflicts between trees can be handled with Coccinelle.
      
      In the future git could get Coccinelle merge support to deal with
      patch --> fail --> grammar --> Coccinelle --> new patch conflicts
      automatically for us on patches where the grammar is available and
      the patch is of high confidence. Consider this a feature request.
      
      Test compiled on x86_64 against:
      
      	* allnoconfig
      	* allmodconfig
      	* allyesconfig
      
      @ const_found @
      identifier ops;
      @@
      
      const struct kernel_param_ops ops = {
      };
      
      @ const_not_found depends on !const_found @
      identifier ops;
      @@
      
      -struct kernel_param_ops ops = {
      +const struct kernel_param_ops ops = {
      };
      
      Generated-by: Coccinelle SmPL
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Junio C Hamano <gitster@pobox.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: cocci@systeme.lip6.fr
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      9c27847d
  22. 11 2月, 2015 1 次提交
  23. 10 2月, 2015 5 次提交
  24. 09 2月, 2015 1 次提交