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

[Andre Oppermann]

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