From owner-freebsd-arch@FreeBSD.ORG Mon Aug 9 18:44:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D5E16A4CE for ; Mon, 9 Aug 2004 18:44:26 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CEE043D48 for ; Mon, 9 Aug 2004 18:44:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1787 invoked from network); 9 Aug 2004 18:44:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Aug 2004 18:44:24 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i79IiDtI076097; Mon, 9 Aug 2004 14:44:16 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org, John-Mark Gurney Date: Mon, 9 Aug 2004 10:26:35 -0400 User-Agent: KMail/1.6 References: <20040806224316.GB991@funkthat.com> In-Reply-To: <20040806224316.GB991@funkthat.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408091026.35755.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: valid dup lock logic for witness X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2004 18:44:26 -0000 On Friday 06 August 2004 06:43 pm, John-Mark Gurney wrote: > I have been working on kqueue, and to support kq in kq, I need to obtain > two kq locks (both of the same type) at the same time. Normally this can > cause a deadlock, but using a proper lock ordering strategy, it can be > avoided. In the kq case, I chose to aquire a kq global lock before > acquiring multiple kq locks. (In the proc case, jhb said you aquire > the child's before the parents.) > > Mutexs have the flag MTX_DUPOK that notify witness that duplicate locks > are ok, but this can hide other problems (and in fact would have in my > testing). > > I have created a patch that lets you inform witness the a duplicate lock > is valid as long as you hold another lock. The only run time change is > that when a duplicate lock is found, it will run through another table > to verify it's ok before printing out the back trace. > > Anyone have objections to this? As I said on IRC, my objection to this is that there are numerous ways of acquiring duplicate locks in a valid fashion. For kq there is a global lock around such cases. For proc locks child processes are locked before parents. The problem is that there is not a single way of doing this, so if you want WITNESS to check all of these, you will have to add lots of special case one-off hacks to WITNESS making it even more obtuse and slow. Perhaps something that might be feasible is to provide some sort of way for other parts of the kernel to register a duplicate check function for a given lock type. This would let you keep the code doing the duplicate check closer to the code using the locks for one thing and would avoid adding N hacks to witness for the various different dup lock checks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org