HEADS UP: tcp wrongly persist timer detection

Sepherosa Ziehau sepherosa at gmail.com
Tue Dec 21 01:33:41 PST 2010

Hi all,

HEAD users only.

It could panic your system upon TCP activities, so please backup your
working kernel :).  If the panic happens, please send us the link to
the core dumps.

Thank you for your help in advance.

Best Regards,

---------- Forwarded message ----------
From: Sepherosa Ziehau <sephe at crater.dragonflybsd.org>
Date: Tue, Dec 21, 2010 at 5:11 PM
Subject: git: tcp: Don't allow persist timer if TCP connection is not
established yet

commit 94603b1beafe1a82c4e61c095b5dcd978c5e8d58
Author: Sepherosa Ziehau <sephe at dragonflybsd.org>
Date:   Tue Dec 21 16:26:34 2010 +0800

   tcp: Don't allow persist timer if TCP connection is not established yet

   This probably could move the un-updated snd_nxt panic earlier.

   The dump of the panic in http://bugs.dragonflybsd.org/issue1939 shows
   - snd_nxt is less than snd_una
   - A persist timer was fired (frame 16, tp->tt_msg->tt_prev_tasks).
   - The TCP segment triggered the panic has SYN|ACK (frame 17, th->th_flags).
     This TCP segment is considered as valid (frame 17, list), so tp->t_state
     was SYN_SENT.

   This explains why snd_nxt is less than snd_una:
   If tcp_output() is called by persist timer, then the persist timer is
   active and the "forced" is turned on, this causes the snd_nxt not updated
   at all.

   How is the persist timer got set in the SYN_SENT in the first place?

   Hope the new panic could lift the veil...

Summary of changes:
 sys/netinet/tcp_output.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)


DragonFly BSD source repository

Tomorrow Will Never Die

More information about the Users mailing list