Skip to content

GitLab

Switch branch/tag
  1. 21 Nov, 2016 1 commit
  3. 11 May, 2016 1 commit
  5. 09 Jul, 2015 1 commit
  7. 29 Apr, 2015 1 commit
  9. 17 Apr, 2015 1 commit
    • Eric Dumazet's avatar
      inet_diag: fix access to tcp cc information · 521f1cf1
      Eric Dumazet authored 
      
Two different problems are fixed here :

1) inet_sk_diag_fill() might be called without socket lock held.
   icsk->icsk_ca_ops can change under us and module be unloaded.
   -> Access to freed memory.
   Fix this using rcu_read_lock() to prevent module unload.

2) Some TCP Congestion Control modules provide information
   but again this is not safe against icsk->icsk_ca_ops
   change and nla_put() errors were ignored. Some sockets
   could not get the additional info if skb was almost full.

Fix this by returning a status from get_info() handlers and
using rcu protection as well.
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      521f1cf1
  11. 02 Sep, 2014 1 commit
  13. 31 Jul, 2014 1 commit
    • Christoph Paasch's avatar
      tcp: Fix integer-overflow in TCP vegas · 1f74e613
      Christoph Paasch authored 
      In vegas we do a multiplication of the cwnd and the rtt. This
may overflow and thus their result is stored in a u64. However, we first
need to cast the cwnd so that actually 64-bit arithmetic is done.

Then, we need to do do_div to allow this to be used on 32-bit arches.

Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Laight <David.Laight@ACULAB.COM>
Cc: Doug Leith <doug.leith@nuim.ie>
Fixes: 8d3a564d

 (tcp: tcp_vegas cong avoid fix)
Signed-off-by: default avatarChristoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f74e613
  15. 03 May, 2014 1 commit
  17. 26 Feb, 2014 1 commit
    • Eric Dumazet's avatar
      tcp: switch rtt estimations to usec resolution · 740b0f18
      Eric Dumazet authored 
      
Upcoming congestion controls for TCP require usec resolution for RTT
estimations. Millisecond resolution is simply not enough these days.

FQ/pacing in DC environments also require this change for finer control
and removal of bimodal behavior due to the current hack in
tcp_update_pacing_rate() for 'small rtt'

TCP_CONG_RTT_STAMP is no longer needed.

As Julian Anastasov pointed out, we need to keep user compatibility :
tcp_metrics used to export RTT and RTTVAR in msec resolution,
so we added RTT_US and RTTVAR_US. An iproute2 patch is needed
to use the new attributes if provided by the kernel.

In this example ss command displays a srtt of 32 usecs (10Gbit link)

lpk51:~# ./ss -i dst lpk52
Netid  State      Recv-Q Send-Q   Local Address:Port       Peer
Address:Port
tcp    ESTAB      0      1         10.246.11.51:42959
10.246.11.52:64614
         cubic wscale:6,6 rto:201 rtt:0.032/0.001 ato:40 mss:1448
cwnd:10 send
3620.0Mbps pacing_rate 7240.0Mbps unacked:1 rcv_rtt:993 rcv_space:29559

Updated iproute2 ip command displays :

lpk51:~# ./ip tcp_metrics | grep 10.246.11.52
10.246.11.52 age 561.914sec cwnd 10 rtt 274us rttvar 213us source
10.246.11.51

Old binary displays :

lpk51:~# ip tcp_metrics | grep 10.246.11.52
10.246.11.52 age 561.914sec cwnd 10 rtt 250us rttvar 125us source
10.246.11.51

With help from Julian Anastasov, Stephen Hemminger and Yuchung Cheng
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Larry Brakmo <brakmo@google.com>
Cc: Julian Anastasov <ja@ssi.bg>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      740b0f18
  19. 13 Feb, 2014 1 commit
  21. 05 Nov, 2013 1 commit
    • Yuchung Cheng's avatar
      tcp: properly handle stretch acks in slow start · 9f9843a7
      Yuchung Cheng authored 
      
Slow start now increases cwnd by 1 if an ACK acknowledges some packets,
regardless the number of packets. Consequently slow start performance
is highly dependent on the degree of the stretch ACKs caused by
receiver or network ACK compression mechanisms (e.g., delayed-ACK,
GRO, etc).  But slow start algorithm is to send twice the amount of
packets of packets left so it should process a stretch ACK of degree
N as if N ACKs of degree 1, then exits when cwnd exceeds ssthresh. A
follow up patch will use the remainder of the N (if greater than 1)
to adjust cwnd in the congestion avoidance phase.

In addition this patch retires the experimental limited slow start
(LSS) feature. LSS has multiple drawbacks but questionable benefit. The
fractional cwnd increase in LSS requires a loop in slow start even
though it's rarely used. Configuring such an increase step via a global
sysctl on different BDPS seems hard. Finally and most importantly the
slow start overshoot concern is now better covered by the Hybrid slow
start (hystart) enabled by default.
Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f9843a7
  23. 10 Mar, 2011 1 commit
  25. 26 May, 2009 1 commit
  27. 09 Dec, 2008 1 commit
    • Doug Leith's avatar
      tcp: tcp_vegas cong avoid fix · 8d3a564d
      Doug Leith authored 
      This patch addresses a book-keeping issue in tcp_vegas.c.  At present
tcp_vegas does separate book-keeping of cwnd based on packet sequence
numbers.  A mismatch can develop between this book-keeping and
tp->snd_cwnd due, for example, to delayed acks acking multiple
packets.  When vegas transitions to reno operation (e.g. following
loss), then this mismatch leads to incorrect behaviour (akin to a cwnd
backoff).  This seems mostly to affect operation at low cwnds where
delayed acking can lead to a significant fraction of cwnd being
covered by a single ack, leading to the book-keeping mismatch.  This
patch modifies the congestion avoidance update to avoid the need for
separate book-keeping while leaving vegas congestion avoidance
functionally unchanged.  A secondary advantage of this modification is
that the use of fixed-point (via V_PARAM_SHIFT) and 64 bit arithmetic
is no longer necessary, simplifying the code.

Some example test measurements with the patched code (confirming no functional
change in the congestion avoidance algorithm) can be seen at:

http://www.hamilton.ie/doug/vegaspatch/

Signed-off-by: default avatarDoug Leith <doug.leith@nuim.ie>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d3a564d
  29. 05 Dec, 2008 1 commit
    • Doug Leith's avatar
      tcp: tcp_vegas ssthresh bug fix · a6af2d6b
      Doug Leith authored 
      
This patch fixes a bug in tcp_vegas.c.  At the moment this code leaves
ssthresh untouched.  However, this means that the vegas congestion
control algorithm is effectively unable to reduce cwnd below the
ssthresh value (if the vegas update lowers the cwnd below ssthresh,
then slow start is activated to raise it back up).  One example where
this matters is when during slow start cwnd overshoots the link
capacity and a flow then exits slow start with ssthresh set to a value
above where congestion avoidance would like to adjust it.
Signed-off-by: default avatarDoug Leith <doug.leith@nuim.ie>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6af2d6b
  31. 01 May, 2008 1 commit
  33. 30 Apr, 2008 1 commit
    • Lachlan Andrew's avatar
      tcp: Overflow bug in Vegas · 15913114
      Lachlan Andrew authored 
      
From: Lachlan Andrew <lachlan.andrew@gmail.com>

There is an overflow bug in net/ipv4/tcp_vegas.c for large BDPs
(e.g. 400Mbit/s, 400ms).  The multiplication (old_wnd *
vegas->baseRTT) << V_PARAM_SHIFT overflows a u32.

[ Fix tcp_veno.c too, it has similar calculations. -DaveM ]
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15913114
  35. 28 Jan, 2008 1 commit
  37. 30 Oct, 2007 1 commit
  39. 31 Jul, 2007 1 commit
  41. 18 Jul, 2007 1 commit
  43. 15 Jun, 2007 1 commit
  45. 26 Apr, 2007 4 commits
  47. 11 Feb, 2007 1 commit
  49. 03 Dec, 2006 1 commit
  51. 22 Sep, 2006 1 commit
  53. 30 Jun, 2006 1 commit
  55. 04 Jan, 2006 1 commit
  57. 07 Dec, 2005 2 commits
  59. 11 Nov, 2005 2 commits
  61. 29 Aug, 2005 3 commits
  63. 23 Jun, 2005 1 commit