From owner-freebsd-net@FreeBSD.ORG Wed Feb 28 09:45:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18D3516A400; Wed, 28 Feb 2007 09:45:42 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7B68813C442; Wed, 28 Feb 2007 09:45:41 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-42-242.51-151.net24.it [151.51.242.42]) (authenticated bits=128) by parrot.aev.net (8.14.0/8.13.8) with ESMTP id l1S9r3Nu033611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Feb 2007 10:53:09 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l1S9juVW034308; Wed, 28 Feb 2007 10:45:57 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45E54F39.4050204@netfence.it> Date: Wed, 28 Feb 2007 10:45:29 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <45E21468.4060200@netfence.it> <20070227222316.R60173@fledge.watson.org> <45E53F7D.4030703@netfence.it> <20070228084928.Y64827@maildrop.int.zabbadoz.net> In-Reply-To: <20070228084928.Y64827@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: LOR with divert sockets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 09:45:42 -0000 Bjoern A. Zeeb wrote: > I am unsure but this should still be true for at least RELENG_6. I > can only remember that there was work in progress but cannot remmember > things were patched and where or not... > > %man ipfw | col -b | grep -5 'Rules which use uid' | tail -7 | head -5 > > Rules which use uid, gid or jail based matching should be used only if > debug.mpsafenet=0 to avoid possible deadlocks due to layering > violations > in its implementation. > > Thanks, this is very interesting. I see this paragraph was added in 6.x, and I admit I never saw it. In fact I had been using uid rules in 5.x without any trouble. Shouldn't this be mentioned in the ERRATA document? I guess no one really reads *all* the man pages again, after an upgrade. First off, I searched for what debug.mpsafe does and came up with some vague description. Are there any reason not to disable this? Second. I grasped the idea that this is important in SMP boxes, but I'm not sure. Does it affect UP boxes too? I'm currently having: _ 1 SMP box *with* one uid rule which occasionally hangs (running INVARIANTS&Co and from which my report was taken); _ 1 SMP box *without* uid rules which occasionally hangs (running INVARIANTS&Co); _ 1 UP box *with* one uid rule which frequently hangs (I'm turning INVARIANTS&Co on this afternoon on this one); _ 1 UP box *with* one uid rule which frequently hangs (I'm turning SMP and INVARIANTS&Co on this afternoon on this one); _ 2 UP boxes *with* one uid rule which never ever hanged. IMHO the uid rule problems could explain half of the data above, but then again, I guess it can also depend on network load, hardware type or other combinations of things. If there are no bigger drawbacks (I don't care for speed as much as I do for stability), I might disable debug.mpsafenet today. Comments? bye & Thanks av.