From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 20:47:18 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711091065686 for ; Wed, 24 Sep 2008 20:47:18 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 6528B8FC13 for ; Wed, 24 Sep 2008 20:47:17 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 24 Sep 2008 20:47:14 -0000 Received: from 85-127-94-178.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.94.178] by mail.gmx.net (mp039) with SMTP; 24 Sep 2008 22:47:14 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX1+GWwB42ayGbxKZezjMq2dFEeWeTqhHTS1cFxlyll dApAaLif4okIZ1 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Wed, 24 Sep 2008 22:47:12 +0200 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) References: <200809231851.42849.shoesoft@gmx.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <200809242247.13189.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58,0.57 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Robert Watson Subject: Re: ipfw: LOR/panic with uid rules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2008 20:47:18 -0000 On Wednesday 24 September 2008 10:08:13 Robert Watson wrote: > On Tue, 23 Sep 2008, Robert Watson wrote: > > On Tue, 23 Sep 2008, Stefan Ehmann wrote: > >> Also posted about this problem recently in stable@. But got no replies > >> there. So I tried on a recent CURRENT but the problem persists: > >> > >> ipfw rules using uid are causing a deadlock. eg. allow ip from any to > >> any uid root A simple HTTP fetch triggers this problem nearly instantly. > >> > >> For me, this problem existed in 6.x with PREEMPTION enabled. It was > >> fixed in 7.0. But in RELENG_7 and head it's back. This is a single > >> processor i386 machine. > > > > This is an interesting edge case -- to prevent lookup of an inpcb in the > > output path, we normally pass the inpcb reference down to the firewall so > > it can directly access the cred rather than looking it up. Thus, we > > don't recurse the global tcbinfo or inpcb locks normally on the transmit > > path. However, it looks like we have an edge case here where we've freed > > the inpcb but not yet unlocked the tcbinfo, and since the inpcb is freed > > we don't pass it down--the firewall code tries to look up the inpcb and > > improperly recurses the tcbinfo lock, boom. > > > > The uid/gid/jail code in ipfw is undesirable for a number of reasons, not > > least because it's a layering violation. Historically, layering > > violations meant slightly awkward and risky recursion, but now they also > > mean lock recursion, which has more serious consequences. I'll > > investigate tomorrow and see what the best solution is -- probably to > > drop the lock before calling tcp_dropwithreset() on a NULL inpcb, which > > is a workaround/hack, but I think our hands are forced in this case. > > I'll follow up with a patch then. > > Here is a possible candidate patch, could you see if it resolves all of the > issues you reported? (Possibly I have missed other similar cases as > well...) Thanks for the patch. Unfortunately the LORs and the panic still remain.