Message ID | 1375747815.4457.59.camel@edumazet-glaptop |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
On Mon, Aug 5, 2013 at 8:10 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > From: Eric Dumazet <edumazet@google.com> > > commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an > overflow error in bictcp_update() in following code : > > /* change the unit from HZ to bictcp_HZ */ > t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - > ca->epoch_start) << BICTCP_HZ) / HZ; > > Because msecs_to_jiffies() being unsigned long, compiler does > implicit type promotion. > > We really want to constrain (tcp_time_stamp - ca->epoch_start) > to a signed 32bit value, or else 't' has unexpected high values. > > This bugs triggers an increase of retransmit rates ~24 days after > boot [1], as the high order bit of tcp_time_stamp flips. > > [1] for hosts with HZ=1000 > > Big thanks to Van Jacobson for spotting this problem. > > Diagnosed-by: Van Jacobson <vanj@google.com> > Signed-off-by: Eric Dumazet <edumazet@google.com> > Cc: Neal Cardwell <ncardwell@google.com> > Cc: Yuchung Cheng <ycheng@google.com> > Cc: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Neal Cardwell <ncardwell@google.com> Also a nice catch! neal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Mon, 05 Aug 2013 17:10:15 -0700 > From: Eric Dumazet <edumazet@google.com> > > commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an > overflow error in bictcp_update() in following code : > > /* change the unit from HZ to bictcp_HZ */ > t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - > ca->epoch_start) << BICTCP_HZ) / HZ; > > Because msecs_to_jiffies() being unsigned long, compiler does > implicit type promotion. > > We really want to constrain (tcp_time_stamp - ca->epoch_start) > to a signed 32bit value, or else 't' has unexpected high values. > > This bugs triggers an increase of retransmit rates ~24 days after > boot [1], as the high order bit of tcp_time_stamp flips. > > [1] for hosts with HZ=1000 > > Big thanks to Van Jacobson for spotting this problem. > > Diagnosed-by: Van Jacobson <vanj@google.com> > Signed-off-by: Eric Dumazet <edumazet@google.com> Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c index a9077f4..b6b591f 100644 --- a/net/ipv4/tcp_cubic.c +++ b/net/ipv4/tcp_cubic.c @@ -206,8 +206,8 @@ static u32 cubic_root(u64 a) */ static inline void bictcp_update(struct bictcp *ca, u32 cwnd) { - u64 offs; - u32 delta, t, bic_target, max_cnt; + u32 delta, bic_target, max_cnt; + u64 offs, t; ca->ack_cnt++; /* count the number of ACKs */ @@ -250,9 +250,11 @@ static inline void bictcp_update(struct bictcp *ca, u32 cwnd) * if the cwnd < 1 million packets !!! */ + t = (s32)(tcp_time_stamp - ca->epoch_start); + t += msecs_to_jiffies(ca->delay_min >> 3); /* change the unit from HZ to bictcp_HZ */ - t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - - ca->epoch_start) << BICTCP_HZ) / HZ; + t <<= BICTCP_HZ; + do_div(t, HZ); if (t < ca->bic_K) /* t - K */ offs = ca->bic_K - t;