From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 10:14:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 665B6106568E; Sat, 27 Sep 2008 10:14:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2FB8FC15; Sat, 27 Sep 2008 10:14:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id CAF8746B37; Sat, 27 Sep 2008 06:14:21 -0400 (EDT) Date: Sat, 27 Sep 2008 11:14:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Christian Laursen In-Reply-To: Message-ID: References: <20080927025017.GA40195@icarus.home.lan> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE freezes (IPFW related) 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: Sat, 27 Sep 2008 10:14:22 -0000 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