1. 17 11月, 2012 1 次提交
  2. 16 11月, 2012 7 次提交
  3. 15 11月, 2012 6 次提交
  4. 14 11月, 2012 1 次提交
    • E
      tcp: tcp_replace_ts_recent() should not be called from tcp_validate_incoming() · bd090dfc
      Eric Dumazet 提交于
      We added support for RFC 5961 in latest kernels but TCP fails
      to perform exhaustive check of ACK sequence.
      
      We can update our view of peer tsval from a frame that is
      later discarded by tcp_ack()
      
      This makes timestamps enabled sessions vulnerable to injection of
      a high tsval : peers start an ACK storm, since the victim
      sends a dupack each time it receives an ACK from the other peer.
      
      As tcp_validate_incoming() is called before tcp_ack(), we should
      not peform tcp_replace_ts_recent() from it, and let callers do it
      at the right time.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Nandita Dukkipati <nanditad@google.com>
      Cc: H.K. Jerry Chu <hkchu@google.com>
      Cc: Romain Francoise <romain@orebokech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd090dfc
  5. 12 11月, 2012 1 次提交
  6. 10 11月, 2012 2 次提交
  7. 04 11月, 2012 2 次提交
    • C
      net: inet_diag -- Return error code if protocol handler is missed · cacb6ba0
      Cyrill Gorcunov 提交于
      We've observed that in case if UDP diag module is not
      supported in kernel the netlink returns NLMSG_DONE without
      notifying a caller that handler is missed.
      
      This patch makes __inet_diag_dump to return error code instead.
      
      So as example it become possible to detect such situation
      and handle it gracefully on userspace level.
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      CC: David Miller <davem@davemloft.net>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      CC: Pavel Emelyanov <xemul@parallels.com>
      Acked-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cacb6ba0
    • E
      tcp: better retrans tracking for defer-accept · e6c022a4
      Eric Dumazet 提交于
      For passive TCP connections using TCP_DEFER_ACCEPT facility,
      we incorrectly increment req->retrans each time timeout triggers
      while no SYNACK is sent.
      
      SYNACK are not sent for TCP_DEFER_ACCEPT that were established (for
      which we received the ACK from client). Only the last SYNACK is sent
      so that we can receive again an ACK from client, to move the req into
      accept queue. We plan to change this later to avoid the useless
      retransmit (and potential problem as this SYNACK could be lost)
      
      TCP_INFO later gives wrong information to user, claiming imaginary
      retransmits.
      
      Decouple req->retrans field into two independent fields :
      
      num_retrans : number of retransmit
      num_timeout : number of timeouts
      
      num_timeout is the counter that is incremented at each timeout,
      regardless of actual SYNACK being sent or not, and used to
      compute the exponential timeout.
      
      Introduce inet_rtx_syn_ack() helper to increment num_retrans
      only if ->rtx_syn_ack() succeeded.
      
      Use inet_rtx_syn_ack() from tcp_check_req() to increment num_retrans
      when we re-send a SYNACK in answer to a (retransmitted) SYN.
      Prior to this patch, we were not counting these retransmits.
      
      Change tcp_v[46]_rtx_synack() to increment TCP_MIB_RETRANSSEGS
      only if a synack packet was successfully queued.
      Reported-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
      Cc: Elliott Hughes <enh@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6c022a4
  8. 03 11月, 2012 1 次提交
  9. 02 11月, 2012 1 次提交
  10. 01 11月, 2012 4 次提交
  11. 29 10月, 2012 4 次提交
  12. 24 10月, 2012 2 次提交
  13. 23 10月, 2012 5 次提交
  14. 19 10月, 2012 2 次提交
  15. 13 10月, 2012 1 次提交