[bouyer%antioche.eu.org@localhost: Re: panic: tcp_output REXMT]

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

Hi,
this is a thread that I started on tech-kern, but it should have been
on tech-net in the first place. Sort story: I'm seeing
panic: tcp_output REXMT
panic() at netbsd:panic+0x1c8
tcp_segsize() at netbsd:tcp_segsize
tcp_timer_persist() at netbsd:tcp_timer_persist+0x73
softclock() at netbsd:softclock+0x2c9
softintr_dispatch() at netbsd:softintr_dispatch+0x99
DDB lost frame for netbsd:Xsoftclock+0x2d, trying 0xffffffff8069bcd0
Xsoftclock() at netbsd:Xsoftclock+0x2d
on a netbsd-3 amd64 public ftp/http server.

----- Forwarded message from Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
-----

Date: Mon, 1 Sep 2008 17:20:08 +0200
From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Subject: Re: panic: tcp_output REXMT
To: tech-kern%NetBSD.org@localhost
X-pt: isis.lip6.fr
In-Reply-To: <20080901142420.GB22583%gumme.math.uni-bonn.de@localhost>
X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.0 
(chassiron.antioche.eu.org [IPv6:2001:7a8:242c:1::1]); Mon, 01 Sep 2008 
17:20:17 +0200 (MEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc7 
(isis.lip6.fr [132.227.60.2]); Mon, 01 Sep 2008 17:20:08 +0200 (CEST)
X-Scanned-By: MIMEDefang 2.63 on 132.227.60.2
List-Id: tech-kern

On Mon, Sep 01, 2008 at 04:24:21PM +0200, Edgar Fuß wrote:
> > Does it ring a bell to someone ?
> RRRRR..yes..INGGG.
> 
> About half a year ago, I found a bug (at least, yamt@ replied that it looked 
> like a bug him) in the TCP timer logic and proposed a patch:
> 
> http://mail-index.netbsd.org/tech-net/2008/02/18/msg000235.html
> 
> where I was wondering why tcp_setpersist() wasn't panicking all the time. 
> Maybe you are just running into that. The bug is most likely to be triggered 
> on a low-MSS-connection with somewhat high packet loss (and SACK enabled).

I could be running in this case; there is indeed SACK enabled, and we could
have low MSS and high packet loss for some clients.

But I don't understand how it could cause a tcp_setpersist() panic. If I
understand it properly, we can't have TCPT_REXMT and TCPT_PERSIST armed
at the same time. Here the path comes from TCPT_PERSIST's handler so
it was armed. Nothing arms TCPT_PERSIST outside of tcp_setpersist(),
so TCPT_REXMT has been armed after TCPT_PERSIST was.

syn_cache_get() can arm TCPT_REXMT without checking TCPT_PERSIST.
I don't know if TCPT_PERSIST could have been armed before at this point.

I couldn't find other places where TCPT_REXMT would be armed without
checking TCPT_PERSIST.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--

----- End forwarded message -----
-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--