From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 20:56:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4232D16A4CF for ; Mon, 20 Dec 2004 20:56:45 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 676E443D5C for ; Mon, 20 Dec 2004 20:56:44 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 81948 invoked from network); 20 Dec 2004 20:44:28 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Dec 2004 20:44:28 -0000 Message-ID: <41C73CBC.9000106@freebsd.org> Date: Mon, 20 Dec 2004 21:57:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Holm References: <20041220194742.GA89598@peter.osted.lan> In-Reply-To: <20041220194742.GA89598@peter.osted.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: rwatson@freebsd.org cc: current@freebsd.org Subject: Re: panic: tcp_input: TCPS_LISTEN in netinet/tcp_input.c:2370 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2004 20:56:45 -0000 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