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. Thanks for the (as usual) excellent bug report! Robert N M WatsonReceived on Wed Feb 16 2005 - 13:03:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:28 UTC