Messages in this thread | | | Subject | Re: timer_bh robusteness fix against potential deadlocks | From | tytso@valinux ... | Date | Wed, 12 Jan 2000 07:59:35 -0800 |
| |
Date: Wed, 12 Jan 2000 04:02:35 +0100 (CET) From: Andrea Arcangeli <andrea@suse.de>
Ok, moving the check inside the tcp_send_delayed_ack it's fine for me.
But there's to say that the only other way the delack timer could be posted is via __tcp_ack_snd_check. And if __tcp_ack_snd_check is using tcp_send_delayed_ack instead of tcp_send_ack before in order packets with data are arrived (so before the ato is been initalized to something different than zero) it probably means there's a genuine bug in tcp.
True; but my paranoia says that even if there isn't a problem *now*, there may be later. Which is why why I'll suggest one more change to your patch:
if (!timeout) { timeout = tp->rto; if (!timeout) panic("Bugcheck: tcp_send_delayed_ack ato and rto are 0"); }
It adds one conditional inside a rare 'if' case, so it's not a performance issue, and it means that the next time something like this happens, the machine will cleanly panic, and leave a very easy to understand indication of what went wrong.
- 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/
| |