Date: Thu, 7 Feb 2008 12:44:14 GMT From: rwatson@FreeBSD.org To: rwatson@FreeBSD.org, freebsd-bugs@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: kern/120344: FreeBSD 6.3-STABLE panics on hight loaded web server Message-ID: <200802071244.m17CiE3u065678@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802071244.m17CiE3u065678>