Messages in this thread Patch in this message | | | Subject | Re: timer_bh robusteness fix against potential deadlocks | From | tytso@valinux ... | Date | Tue, 11 Jan 2000 18:03:40 -0800 |
| |
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/
| |