From owner-freebsd-bugs@FreeBSD.ORG  Thu Feb  7 12:44:14 2008
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A32DB16A419;
	Thu,  7 Feb 2008 12:44:14 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 8909C13C469;
	Thu,  7 Feb 2008 12:44:14 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m17CiEMK065682;
	Thu, 7 Feb 2008 12:44:14 GMT
	(envelope-from rwatson@freefall.freebsd.org)
Received: (from rwatson@localhost)
	by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m17CiE3u065678;
	Thu, 7 Feb 2008 12:44:14 GMT (envelope-from rwatson)
Date: Thu, 7 Feb 2008 12:44:14 GMT
Message-Id: <200802071244.m17CiE3u065678@freefall.freebsd.org>
To: rwatson@FreeBSD.org, freebsd-bugs@FreeBSD.org, rwatson@FreeBSD.org
From: rwatson@FreeBSD.org
Cc: 
Subject: Re: kern/120344: FreeBSD 6.3-STABLE panics on hight loaded web
	server
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2008 12:44:14 -0000

Synopsis: FreeBSD 6.3-STABLE panics on hight loaded web server

Responsible-Changed-From-To: freebsd-bugs->rwatson
Responsible-Changed-By: rwatson
Responsible-Changed-When: Thu Feb 7 12:40:58 UTC 2008
Responsible-Changed-Why: 
Grab ownership since I've done some initial diagnosis by IRC; it looks
like accf_data is calling soisconnected() from soisdisconnected(), and
then stumbling over the fact that so_head points at a socket that also
has a non-NULL so_head.  It's not lear to me whether the isconnnected->
disconnected path is leading somehow to this problem, or that this
rather odd state is "normal" and I'm only noticing it because of the
panic.  I think the best path forward is to try and reproduce the
accf_data "odd" state using a bit of low-level packet robbing and see
if it leads to the panic.  If not, then, while we should take a todo
list item on improving accf_data and accept filter behavior, adding
more diagnostics in order to catch this problem earlier is probably
the way forward -- perhaps at the top of this call stack assert that
so_head->so_head is NULL, and then at the bottom, so that if the
bottom assertion fires, then it happened after the top assertion.
I'll look at reproducing this locally and see how it goes.


http://www.freebsd.org/cgi/query-pr.cgi?pr=120344