From owner-cvs-all@FreeBSD.ORG Wed Apr 2 08:06:35 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01C0F106566B; Wed, 2 Apr 2008 08:06:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6F468FC1B; Wed, 2 Apr 2008 08:06:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4BB6E46C31; Wed, 2 Apr 2008 04:06:34 -0400 (EDT) Date: Wed, 2 Apr 2008 09:06:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <20080401210738.E72156@desktop> Message-ID: <20080402090327.D14932@fledge.watson.org> References: <200804012031.m31KVtKs000176@repoman.freebsd.org> <3bbf2fe10804011723w69e38ed7sc5760ea269600654@mail.gmail.com> <20080401150918.F72156@desktop> <200804020412.30624.max@love2party.net> <20080401210738.E72156@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , Max Laier , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_rwlock.c src/sys/sys rwlock.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 08:06:35 -0000 On Tue, 1 Apr 2008, Jeff Roberson wrote: >> I don't think this is a good thing either, but I also think that there are >> some cases where there just are different access orders. I'd rather want a >> clean way out of this than a lot of difficult per-instance hacks. This >> does not mean that these can't be fixed cleanly, but I think it's really >> hard sometimes especially for code we import from elsewhere (hence the >> personal interest). > > I think the best solution is to treat rlocks as wlocks in terms of access > orders. The 'problem' is that there are certain usage cases for rwlocks where 99% of paths use only recursive read locks, with rather incestuous lock orders with respect to other locks, and 1% of paths use write locks and are very conservative about the calling path. I'm sure the example that Max has in mind is pfil, where you may get pfil invocation as you enter the stack or as you exit it, but whose lock should not ever lead to deadlock as it's only acquired readable in those paths. The key missing bit of the picture is that the write path must be constructed very, very carefully so that it is never called holding any locks that interact with the read locks. What would be very nice is if witness fired if the write path got it wrong in those cases, since using rwlocks effectively as a reference count to prevent subsystem reconfiguration while in use is a structure likely to be used elsewhere. Robert N M Watson Computer Laboratory University of Cambridge