From owner-freebsd-stable@FreeBSD.ORG Fri Jul 21 09:15:54 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 7E75616A4DE; Fri, 21 Jul 2006 09:15:54 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C4C43D45; Fri, 21 Jul 2006 09:15:53 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6L9FnPA012187 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 11:15:50 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6L9FnxU003713; Fri, 21 Jul 2006 11:15:49 +0200 (MEST) Date: Fri, 21 Jul 2006 11:15:49 +0200 From: Daniel Hartmeier To: Michal Mertl Message-ID: <20060721091549.GC23227@insomnia.benzedrine.cx> References: <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153472248.1140.13.camel@genius.i.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1153472248.1140.13.camel@genius.i.cz> User-Agent: Mutt/1.5.10i Cc: Max Laier , freebsd-stable@freebsd.org, freebsd-pf@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: Fri, 21 Jul 2006 09:15:54 -0000 On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote: > The proxy in fact runs in parallel (according to "pfctl -s info" it did > about 50 inserts and removal in the state table per second - some 10Mbit > of traffic, probably mostly HTTP) and it is quite possible that your > explanation is correct. I will forward your suspicion to the vendor. > This functionality of the software (using PF with anchors) is quite new > - they used different mechanisms in previous versions so it may well > have some bugs. Anchors were introduced for this purpose, i.e. splitting the ruleset into separate pieces, over each of which a single process can have authority, so different processes don't stomp on each other's toes with ruleset modifications. Ask them if they really need to still use DIOCCHANGERULE, as the idea with anchors is generally to only operate within one anchor, and usually flush or replace the (smaller) ruleset within. Each anchor has its own ticket, so if you're seeing ticket mismatches, that means there are concurrent operations on the same anchor, even. Daniel