Date: Mon, 20 Dec 2004 21:57:32 +0100 From: Andre Oppermann <andre@freebsd.org> To: Peter Holm <peter@holm.cc> Cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 Message-ID: <41C73CBC.9000106@freebsd.org> In-Reply-To: <20041220194742.GA89598@peter.osted.lan> References: <20041220194742.GA89598@peter.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Holm wrote: > During stress test with GENERIC HEAD from Dec 20 12:18 UTC I got: > > panic(c08374d0,8,c08f46e0,c1523170,3e0) at panic+0x190 > tcp_input(c2877900,14,2,c082b363,246) at tcp_input+0x2689 > ip_input(c2877900,18,c091a0b8,cbc7fcf4,c0681867) at ip_input+0xd6 > netisr_processqueue(c154a080,c154c180,c1523170,cbc7fd1c,c05ffa66) > at netisr_processqueue+0xf > swi_net(0,0,0,c1554bd0,0) at swi_net+0x8b > ithread_loop(c154c180,cbc7fd48,c154c180,c05ff8c8,0) at > ithread_loop+0x19e > fork_exit(c05ff8c8,c154c180,cbc7fd48) at fork_exit+0x7e > fork_trampoline() at fork_trampoline+0x8 > > http://www.holm.cc/stress/log/cons96.html Duh. This is really strange. t_state is 0x1 which is TCPS_LISTEN. Listen is only checked on the socket not on the tcpcb. However there is a panic after "after_listen:" that checks for exactly TCPS_LISTEN. It should never have made it past this one. That it did suggests some kind of race condition wrt. sockets and the tcpcb creation for the listening socket. Though even more strange is how this KASSERT can be reached; Only if the segment has FIN set. /me puzzled. Ok, we know the segment had FIN set. We know the tcpcb is in LISTEN state. We know in_pcblookup_hash() found this inpcb. We don't know how the segment processing made it past all the checks prior to this KASSERT. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C73CBC.9000106>