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

On Wed, Feb 16, 2005 at 02:01:48PM +0000, Robert Watson wrote:
> 
> On Mon, 7 Feb 2005, Peter Holm wrote:
> 
> > While stress testing GENERIC HEAD from Feb 5 09:19 UTC + mpsafe_vfs = 1
> > I got:
> > 
> > panic(c0832f7d,0,0,1,0) at panic+0x14b
> > tcp_input(c27fca00,14,c27fca00,0,0) at tcp_input+0xbf6
> > ip_input(c27fca00) at ip_input+0x50d
> > netisr_processqueue(c0944cd8) at netisr_processqueue+0x6e
> > swi_net(0) at swi_net+0xbe
> > ithread_loop(c154d180,cbc90d48,c154d180,c0601f84,0) at ithread_loop+0x120
> > fork_exit(c0601f84,c154d180,cbc90d48) at fork_exit+0xa4
> > fork_trampoline() at fork_trampoline+0x8
> > 
> > Details at http://www.holm.cc/stress/log/cons115.html
> > A KTR dump with KTR_LOCK|KTR_BUF is available.
> > 
> > Related reports:
> > 
> > -rw-r--r--  1 holm  users  10641 Dec 20 16:51 cons96.html
> > -rw-r--r--  1 holm  users   9906 Dec 26 15:28 cons98.html
> > -rw-r--r--  1 holm  users  15189 Dec 29 22:17 cons99.html
> 
> This would appear to be an inter-layer race between the socket code and
> the TCP code.  In particular, it looks like a SYN has come in during the
> call to listen() on another CPU (or perhaps a preempted thread), after the
> TCP state has been set up for the listening tcpcb, but before the
> SO_ACCEPTCONN flag is set in the socket state.  The TCP code panics
> because it expects that if a tcpcb is in TCPS_LISTEN, the matching socket
> should be in SO_ACCEPTCONN.  I'm working on a patch and hope to put it
> together for you today.  However, this patch substantially tears up the
> current listen code for several protocols, so it will need a fair amount
> of testing.
> 
> If this problem should occur again, it would be very interesting to know
> if ps, show threads, trace, et al, showed either a preempted thread on the
> current CPU, or a thread on another CPU, in the listen() system call.
> 

I had saved a copy of the kernel + core so here's a ps +
backtraces:

http://www.holm.cc/stress/log/cons115a.html

This is a single CPU box, but process 75980 has a listen() in the
backtrace.

> Thanks for the (as usual) excellent bug report!
> 
> Robert N M Watson

You're welcome. It is always great to get feedback on the testing
I'm doing.

-- 
Peter Holm