The following reply was made to PR kern/176667; it has been noted by GNATS.
From: Gleb Smirnoff <gleb...@freebsd.org>
To: Lutz Donnerhacke <l...@iks-service.de>
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/176667: libalias locks on uninitalized data
Date: Thu, 7 Mar 2013 20:30:26 +0400
On Tue, Mar 05, 2013 at 03:54:50PM +0000, Lutz Donnerhacke wrote:
L>
L> >Number: 176667
L> >Category: kern
L> >Synopsis: libalias locks on uninitalized data
L> >Confidential: no
L> >Severity: non-critical
L> >Priority: low
L> >Responsible: freebsd-bugs
L> >State: open
L> >Quarter:
L> >Keywords:
L> >Date-Required:
L> >Class: sw-bug
L> >Submitter-Id: current-users
L> >Arrival-Date: Tue Mar 05 16:00:00 UTC 2013
L> >Closed-Date:
L> >Last-Modified:
L> >Originator: Lutz Donnerhacke
L> >Release: FreeBSD 8.3-RELEASE (GENERIC)
L> >Organization:
L> IKS Service GmbH
L> >Environment:
L> FreeBSD server7.net.encoline.de 8.3-RELEASE FreeBSD 8.3-RELEASE #0: Mon Apr
9 21:23:18 UTC 2012
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
L>
L> >Description:
L> While testing terminating a huge number of PPPoX clients the kernel panics
while doing in-kernel NAT.
L>
L> #4 0xffffffff808e8775 at calltrap+0x8
L> #5 0xffffffff80fa0f01 at HouseKeeping+0xa1
L> #6 0xffffffff80f9e6ab at LibAliasOutLocked+0x3b
L>
L> Please note, that the stack trace is incomplete. There are calls to
IncrementalCleanup() and DeleteLink(), which are not reported in the stack
trace.
L>
L> The problem seems to come from incorrect locking, so the contents of the
libalias database get corrupted.
L>
L> This patch might be not the full solution, but is an obvious fix for an
obvious bug.
L> >How-To-Repeat:
L> Setting up ipfw nat, add more then 9000 clients using mpd5.6, generate
traffic
L> >Fix:
L> --- sys/netinet/libalias/alias_db.c.ORIG 2013-03-05
16:49:13.000000000 +0100
L> +++ sys/netinet/libalias/alias_db.c 2013-03-05 16:50:09.000000000 +0100
L> @@ -2767,8 +2767,8 @@
L> struct ip_fw rule; /* On-the-fly built rule */
L> int fwhole; /* Where to punch hole */
L>
L> - LIBALIAS_LOCK_ASSERT(la);
L> la = lnk->la;
L> + LIBALIAS_LOCK_ASSERT(la);
L>
L> /* Don't do anything unless we are asked to */
L> if (!(la->packetAliasMode & PKT_ALIAS_PUNCH_FW) ||
L> @@ -2841,8 +2841,8 @@
L> {
L> struct libalias *la;
L>
L> - LIBALIAS_LOCK_ASSERT(la);
L> la = lnk->la;
L> + LIBALIAS_LOCK_ASSERT(la);
L> if (lnk->link_type == LINK_TCP) {
L> int fwhole = lnk->data.tcp->fwhole; /* Where is the
firewall
L> * hole? */
The code edited isn't correct and the patch is neither.
The fw punching isn't supported when libalias is compiled into kernel.
The LIBALIAS_LOCK_ASSERT(la) on not initialized variable couldn't even
pass compiler, if only the entire fw punching code was enabled.
So these lines need to be just removed for sanity. Unfortunately this isn't
related to panic you are hitting.
Do you have cores of that panic?
--
Totus tuus, Glebius.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
