Date: Sat, 27 Sep 2008 11:14:21 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Christian Laursen <xi@borderworlds.dk> Cc: Jeremy Chadwick <koitsu@FreeBSD.org>, freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE freezes (IPFW related) Message-ID: <alpine.BSF.1.10.0809271105410.20117@fledge.watson.org> In-Reply-To: <ygf63oiortu.fsf_-_@dominion.borderworlds.dk> References: <ygfabdu6fpu.fsf@dominion.borderworlds.dk> <20080927025017.GA40195@icarus.home.lan> <ygf63oiortu.fsf_-_@dominion.borderworlds.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Sep 2008, Christian Laursen wrote: > I am now back to running with everything I usually have running on this > machine (my primary desktop) but without the ipfw uid rules and the machine > is rock stable. > > I have been running with debug.mpsafenet="0" most likely because I have been > using ipfw uid matching. Has RELENG_7 had significant changes in this area? > > Since I don't need these rules anymore I have just removed them. In the last few days, some previously undiscovered interactions have been discovered between the rwlock work for udp/tcp performance and ipfw uid/gid/jail rules. In essence, there were a number of edge cases where it turned out ipfw was relying on lock recursion on those locks, and that's no longer possible. I've fixed two such edge cases in HEAD and will MFC them shortly, but there is at least one other known case. I'm on the fence about whether to continue playing whack-a-mole knocking off the bugs as they are discovered, and fixing it with a hammer (having ipfw and friends check for the lock held before trying to acquire it) -- if this keeps up it's the latter for -STABLE and continuing to fix them as one-off bugs in HEAD. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0809271105410.20117>