Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370

On Mon, Dec 20, 2004 at 09:57:32PM +0100, Andre Oppermann wrote:
> 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

Here's a new one: http://www.holm.cc/stress/log/cons98.html

-- 
Peter Holm