From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 26 07:14:45 2007 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4814D16A41B; Wed, 26 Dec 2007 07:14:45 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.200.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6592F13C45B; Wed, 26 Dec 2007 07:14:44 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:63221 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S8372648AbXLZG5s (ORCPT + 1 other); Wed, 26 Dec 2007 09:57:48 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp1 X-Yandex-TimeMark: 1198652268 X-MsgDayCount: 3 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <4771FB69.6070900@yandex.ru> Date: Wed, 26 Dec 2007 09:57:45 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: kris@FreeBSD.org References: <200712251415.lBPEFFtQ005961@freefall.freebsd.org> In-Reply-To: <200712251415.lBPEFFtQ005961@freefall.freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, maksim_l@mail.ru Subject: Re: kern/118993: [ipfw] page fault - probably it's a locking problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 07:14:45 -0000 kris@FreeBSD.org wrote: > State-Changed-When: Tue Dec 25 14:14:45 UTC 2007 > State-Changed-Why: > Oops, it was actually a recursive panic and the first one is indeed > ipfw-related. The ipfw ruleset would still help though. I'm not sure that Maxim (a person who got the problem) can publish his rules. But as i know there is a typical firewall-script (`ipfw -f flush` and a lot of other rules). As i see in the code, panic is in the line 2538: if (set_disable & (1 << f->set) ) continue; I think panic here can be only when "f" is invalid. I'm right? But it seems protected with IPFW_RLOCK... -- WBR, Andrey V. Elsukov