From owner-freebsd-stable@FreeBSD.ORG Thu Jul 20 16:02:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440A916A4DA for ; Thu, 20 Jul 2006 16:02:04 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail.secureworks.net (mail.secureworks.net [65.114.32.155]) by mx1.FreeBSD.org (Postfix) with SMTP id B30B343D53 for ; Thu, 20 Jul 2006 16:02:03 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: (qmail 24965 invoked from network); 20 Jul 2006 16:02:01 -0000 Received: from unknown (HELO ?192.168.14.135?) (63.239.86.253) by 0 with SMTP; 20 Jul 2006 16:02:01 -0000 Message-ID: <44BFA8F9.8010403@jellydonut.org> Date: Thu, 20 Jul 2006 12:02:01 -0400 From: Michael Proto User-Agent: Thunderbird 1.5.0.4 (X11/20060627) MIME-Version: 1.0 To: Michal Mertl References: <1153410809.1126.66.camel@genius.i.cz> In-Reply-To: <1153410809.1126.66.camel@genius.i.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel panic with PF X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 16:02:04 -0000 Michal Mertl wrote: > Hello, > > I am deploying FreeBSD based application proxies' based firewall > (www.kernun.com, but not much English there) and am having frequent > panics of RELENG_6_1 under load. The server has IP forwarding disabled. > > I've got two machines in a carp cluster and the transparent proxies use > PF to get the data. > > I don't know much about kernel internals and PF but from the following > backtrace I understand that the crash happens because rpool->cur on line > 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It > probably shouldn't happen yet it does. > > The machines are SMP and were running SMP kernel. The only places where > pool.cur (or pool->cur) is assigned to are in pf_ioctl.c. It seems there > are some lock operations though so it is probably believed that the > coder is properly locked. > > I have been running with kern.smp.disabled=1 for a moment before I put > the old firewall in place and haven't seen the panic but the time was > deffinitely too short to make me believe it fixes the issue. Can setting > debug.mpsafenet to 0 possibly also help? > ... Are you using user and/or group rules in your PF ruleset? If so, then you will want to set debug.mpsafenet to 0 as its a known issue with pf(4) currently. -Proto