lkml.org 
[lkml]   [2000]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: timer_bh robusteness fix against potential deadlocks
From
Date
   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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.050 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site