From owner-freebsd-stable@FreeBSD.ORG Mon Jul 24 11:21:01 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 AA96E16A4DA for ; Mon, 24 Jul 2006 11:21:01 +0000 (UTC) (envelope-from mb@tns.cz) Received: from pha.tns.cz (pha.tns.cz [85.207.56.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 201D743D5F for ; Mon, 24 Jul 2006 11:20:59 +0000 (GMT) (envelope-from mb@tns.cz) Received: from pha.tns.cz (localhost [127.0.0.1]) by pha.tns.cz (Postfix) with ESMTP id 45E7B273509 for ; Mon, 24 Jul 2006 13:20:58 +0200 (CEST) Received: by pha.tns.cz with ESMTP id 49H5D340000WWYQBDFW; Mon, 24 Jul 2006 13:20:57 +0200 (CEST) Date: Mon, 24 Jul 2006 13:20:56 +0200 From: Martin Beran To: freebsd-stable@freebsd.org Message-ID: <20060724112056.GA8744@mb.tns.cz> References: <20060721010559.GB23227@insomnia.benzedrine.cx> <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153433881.1173.3.camel@genius.i.cz> <1153410809.1126.66.camel@genius.i.cz> <44BFA8F9.8010403@jellydonut.org> <1153410809.1126.66.camel@genius.i.cz> <20060721161522.GA10111@mb.tns.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060721161522.GA10111@mb.tns.cz> User-Agent: Mutt/1.4.2.1i X-Kernun-Loop-Info: 1 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: Mon, 24 Jul 2006 11:21:01 -0000 On Fri, Jul 21, 2006 at 02:15:33PM +0000, Martin Beran wrote: > I think this is not the case. The proxy uses either DIOCXBEGIN + DIOCBEGINADDRS > + DIOCADDADDR + DIOCADDRULE + DIOCXCOMMIT or > DIOCCHANGERULE(PF_CHANGE_GET_TICKET) + DIOCBEGINADDRS + DIOCADDADDR > + DIOCCHANGERULE(PF_CHANGE_ADD_TAIL). The first method is used in the first > call to create the ruleset. In the subsequent call, the second method is used > to modify the ruleset. I did an experiment - repeated adding and deleting rules in two processes, as fast as possible. I expected EBUSY from time to time, but I also received EINVAL indeterministically. It seems to me that when the PF ioctl() is called simultaneously by two processes, it sometimes retuns EINVAL, although it sould be possible to either complete the operation (parameters are correct), or return EBUSY. -- Martin Beran Senior Developer Trusted Network Solutions, a.s. mobil: +420 603 820 932 [ www.tns.cz ]