From owner-cvs-src@FreeBSD.ORG Tue Mar 30 11:06:44 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7576616A4CE; Tue, 30 Mar 2004 11:06:44 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14A0443D48; Tue, 30 Mar 2004 11:06:44 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i2UJ4IxC097443; Tue, 30 Mar 2004 14:04:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i2UJ4ImV097440; Tue, 30 Mar 2004 14:04:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 30 Mar 2004 14:04:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nate Lawson In-Reply-To: <20040330105844.B81785@root.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sys_socket.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 19:06:44 -0000 On Tue, 30 Mar 2004, Nate Lawson wrote: > On Sun, 28 Mar 2004, Robert Watson wrote: > > Modified files: > > sys/kern sys_socket.c > > Log: > > Conditionally acquire Giant when entering the socket layer via file > > descriptor operations based on debug.mpsafenet, rather than acquiring > > Giant unconditionally. > > > > Revision Changes Path > > 1.56 +6 -6 src/sys/kern/sys_socket.c > > This adds a small race if someone happens to disable debug.mpsafenet > while a thread is holding Giant. This may not be an issue since this is > only a debugging sysctl and shouldn't be changed during network > operation. Still, it's important to note this. debug.mpsafenet is only modifiable as a tunable; as a sysctl, it's read-only. It's critical that this remain the case, or Very Bad Things Might Happen, especially given that accesses to debug.mpsafenet aren't synchronized so you can get stale values if it's changed, as well as the sorts of races you've identified. :-) > I've been finishing up ACPI locking and revisited a similar issue in the > embedded controller driver. When changing use of the global lock, I > acquire the outer lock so I am certain no one is holding the inner lock > and neglects to release it on the way out of a function because the > global lock flag changed. For the purposes of the network stack locking work, I think supporting run-time change of the policy isn't really useful to us -- at least, not at the cost of finding a more flexible solution that's also more expensive. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research