Date: Wed, 12 Jan 2000 02:49:56 +0100 (CET)
From: Andrea Arcangeli <andrea@suse.de>
As TyTso suggested the problem could be ato to be zero. I checked and I
finally also spotted the offending bug that was causing the above
condition to happen (second chunk of the patch):
--- 2.2.14-tcp/net/ipv4/tcp_output.c.~1~ Fri Jan 7 18:19:25 2000
+++ 2.2.14-tcp/net/ipv4/tcp_output.c Wed Jan 12 02:47:32 2000
@@ -1004,7 +1004,7 @@
unsigned long timeout;
/* Stay within the limit we were given */
- timeout = tp->ato;
+ timeout = (tp->ato << 1) >> 1;
if (timeout > max_timeout)
timeout = max_timeout;
timeout += jiffies;
Note that max_timeout is always a small positive number (HZ/2 or HZ/10),
and timeout is a unsigned long. Hence if the quickack bit is set,
timeout is > max_timeout, and so timeout gets capped to max_timeout.
Without the patch, we simply delay the hack by the max_timeout instead
of the current value of ato. Probably not the best, but not a disaster,
either.
@@ -1044,6 +1044,8 @@
*/
if(tcp_in_quickack_mode(tp))
tcp_exit_quickack_mode(tp);
+ if (!tp->ato)
+ tp->ato = tp->rto;
tcp_send_delayed_ack(tp, HZ/2);
return;
}
This fixes the bug, but I'd be much happier if we put a
belt-and-suspenders check in tcp_send_delayed_ack. If there's some
other place which allows tcp_send_delayed_ack() to be called with
tp->ato set to zero, we shouldn't lock up the entire kernel.
So I'd propose adding to the tcp_send_delayed_ack() something like this:
#define min_timeout HZ/50
if (timeout < min_timeout)
timeout = min_timeout; /* This prevents an endless kernel loop */
(who me, paranoid?)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:23 EST