Hi,

I had a divide by zero on kernel 2.4.33 running with Vegas enabled.
The KDB back trace is:
kdb> bt
Stack traceback for pid 0
0x403a6000        0        0  1    0   R  0x403a6370 *swapper
EBP        EIP        Function (args)
0x403a7d48 0x4026ae51 vegas_cong_avoid+0x111 (0x5f3bb638, 0x73c92cbb, 0xffffffff
, 0x73c92cbb, 0xf28d0275)
                               kernel .text 0x40100000 0x4026ad40 0x4026aef0
0x403a7d8c 0x4026bb67 tcp_ack+0x307 (0x5f3bb560, 0x581985c0, 0x18e, 0x4023e765,
0x5c369044)
                               kernel .text 0x40100000 0x4026b860 0x4026be20
0x403a7ddc 0x4026e771 tcp_rcv_established+0x461 (0x5f3bb560, 0x581985c0, 0x5c369
044, 0x2c, 0x5f3bb638)
                               kernel .text 0x40100000 0x4026e310 0x4026ed80
0x403a7e00 0x40277c2f tcp_v4_do_rcv+0x14f (0x5f3bb560, 0x581985c0, 0x0, 0x403a7e
50, 0x4024bb42)
                               kernel .text 0x40100000 0x40277ae0 0x40277c40
<Rest was cut for readability>
What happens is that vegas_rtt_calc() gets rtt as -1, so when it adds
1 the rtt is set to zero.
It seems that the -1 came from tcp_clean_rtx_queue() so I made this
small patch to fix the problem. I think it is also relevant to 2.6.


Don't perform congestion avoidance on packets that we didn't calculate
there RTT, as this may result in a divide by zero later on.

Signed-off-by: Lior Dotan <redacted>
---

diff -up net/ipv4/tcp_input.c.orig net/ipv4/tcp_input.c

--- net/ipv4/tcp_input.c.orig   2007-05-29 11:43:37.000000000 +0300
+++ net/ipv4/tcp_input.c        2007-05-29 11:20:21.000000000 +0300

@@ -2425,6 +2424,7 @@ static int tcp_clean_rtx_queue(struct so
                                        tp->retrans_out--;
                                acked |= FLAG_RETRANS_DATA_ACKED;
                                seq_rtt = -1;
+                               acked &= ~FLAG_DATA_ACKED;
                        } else if (seq_rtt < 0)
                                seq_rtt = now - scb->when;
                        if(sacked & TCPCB_SACKED_ACKED)
-