From owner-freebsd-arch@FreeBSD.ORG Thu Aug 12 13:50:56 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 6F92116A4CE for ; Thu, 12 Aug 2004 13:50:56 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 440F743D31 for ; Thu, 12 Aug 2004 13:50:56 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16265 invoked from network); 12 Aug 2004 13:50:56 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Aug 2004 13:50:55 -0000 Received: from [10.50.41.91] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7CDop20099923; Thu, 12 Aug 2004 09:50:52 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org, John-Mark Gurney Date: Thu, 12 Aug 2004 09:23:42 -0400 User-Agent: KMail/1.6.2 References: <20040806224316.GB991@funkthat.com> <200408091026.35755.jhb@FreeBSD.org> <20040812055712.GC991@funkthat.com> In-Reply-To: <20040812055712.GC991@funkthat.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408120923.42973.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: Thu, 12 Aug 2004 13:50:56 -0000 On Thursday 12 August 2004 01:57 am, John-Mark Gurney wrote: > John Baldwin wrote this message on Mon, Aug 09, 2004 at 10:26 -0400: > > 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. > > How about that, but making the dup lock ok w/ a signle parent lock a > generic function. I would imagine there are a finite number of ways > to solve duplicate locks, and they will end up being shared between > different subsystems. Making it a generic function will be slower. You can have the kqueue dup check function look something like: int kqueue_check_dup(struct lock_object *l1, struct lock_object *l2) { return (mtx_owned(&kqueue_master_dup_lock)); } (Where the dup function returns 1 if the dup is ok and 0 if it is not). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/