1. 20 9月, 2016 1 次提交
    • C
      SUNRPC: Generalize the RPC buffer allocation API · 5fe6eaa1
      Chuck Lever 提交于
      xprtrdma needs to allocate the Call and Reply buffers separately.
      TBH, the reliance on using a single buffer for the pair of XDR
      buffers is transport implementation-specific.
      
      Transports that want to allocate separate Call and Reply buffers
      will ignore the "size" argument anyway.  Don't bother passing it.
      
      The buf_alloc method can't return two pointers. Instead, make the
      method's return value an error code, and set the rq_buffer pointer
      in the method itself.
      
      This gives call_allocate an opportunity to terminate an RPC instead
      of looping forever when a permanent problem occurs. If a request is
      just bogus, or the transport is in a state where it can't allocate
      resources for any request, there needs to be a way to kill the RPC
      right there and not loop.
      
      This immediately fixes a rare problem in the backchannel send path,
      which loops if the server happens to send a CB request whose
      call+reply size is larger than a page (which it shouldn't do yet).
      
      One more issue: looks like xprt_inject_disconnect was incorrectly
      placed in the failure path in call_allocate. It needs to be in the
      success path, as it is for other call-sites.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      5fe6eaa1
  2. 03 9月, 2016 1 次提交
  3. 06 8月, 2016 2 次提交
  4. 05 8月, 2016 1 次提交
    • N
      SUNRPC: disable the use of IPv6 temporary addresses. · d88e4d82
      NeilBrown 提交于
      If the net.ipv6.conf.*.use_temp_addr sysctl is set to '2',
      then TCP connections over IPv6 will prefer a 'private' source
      address.
      These eventually expire and become invalid, typically after a week,
      but the time is configurable.
      
      When the local address becomes invalid the client will not be able to
      receive replies from the server.  Eventually the connection will timeout
      or break and a new connection will be established, but this can take
      half an hour (typically TCP connection break time).
      
      RFC 4941, which describes private IPv6 addresses, acknowledges that some
      applications might not work well with them and that the application may
      explicitly a request non-temporary (i.e. "public") address.
      
      I believe this is correct for SUNRPC clients.  Without this change, a
      client will occasionally experience a long delay if private addresses
      have been enabled.
      
      The privacy offered by private addresses is of little value for an NFS
      server which requires client authentication.
      
      For NFSv3 this will often not be a problem because idle connections are
      closed after 5 minutes.  For NFSv4 connections never go idle due to the
      period RENEW (or equivalent) request.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      d88e4d82
  5. 02 8月, 2016 1 次提交
  6. 20 7月, 2016 3 次提交
  7. 15 6月, 2016 1 次提交
  8. 14 6月, 2016 4 次提交
  9. 18 5月, 2016 1 次提交
  10. 13 5月, 2016 1 次提交
  11. 28 4月, 2016 1 次提交
  12. 14 4月, 2016 1 次提交
  13. 12 4月, 2016 1 次提交
  14. 06 2月, 2016 1 次提交
  15. 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
  16. 28 12月, 2015 1 次提交
  17. 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
  18. 04 11月, 2015 1 次提交
  19. 03 11月, 2015 2 次提交
  20. 24 10月, 2015 1 次提交
  21. 08 10月, 2015 5 次提交
  22. 20 9月, 2015 1 次提交
  23. 18 9月, 2015 2 次提交
  24. 30 8月, 2015 2 次提交
  25. 20 8月, 2015 1 次提交
  26. 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
  27. 28 7月, 2015 1 次提交