From owner-freebsd-arch@FreeBSD.ORG Thu Aug 25 12:00:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4261106566C; Thu, 25 Aug 2011 12:00:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5042D8FC29; Thu, 25 Aug 2011 12:00:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E6F1B46B2D; Thu, 25 Aug 2011 08:00:08 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 88A3D8A02F; Thu, 25 Aug 2011 08:00:08 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Thu, 25 Aug 2011 08:00:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E53986B.5000804@FreeBSD.org> <201108251235.15853.hselasky@c2i.net> <4E563354.5020106@FreeBSD.org> In-Reply-To: <4E563354.5020106@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108250800.07467.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 25 Aug 2011 08:00:08 -0400 (EDT) Cc: freebsd-arch@freebsd.org, Hans Petter Selasky Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 12:00:09 -0000 On Thursday, August 25, 2011 7:34:44 am Andriy Gapon wrote: > on 25/08/2011 13:35 Hans Petter Selasky said the following: > > On Tuesday 23 August 2011 15:11:08 John Baldwin wrote: > >>> I. [Why] do we need this pattern? > >>> Can the code be re-written in a smarter (if not to say proper) way? > >> > > > > Hi, > > > >> Giant is recursive, it should just be always acquired. Also, this > >> recursive call pattern is very non-obvious. A far more straightforward > >> approach would be to just have: > > > > Unless Witness is changed, that won't work. It will lead to LOR warnings I > > think. > > > > Imagine that the root function locks Giant, then another lock is locked and > > then ukbd_poll() is called. Won't the second lock of Giant cause a LOR > > warning? > > I think no. > At least that's how I interpret the following snippet in witness_checkorder(): > /* > * Check to see if we are recursing on a lock we already own. If > * so, make sure that we don't mismatch exclusive and shared lock > * acquires. > */ > lock1 = find_instance(lock_list, lock); > if (lock1 != NULL) { > if ((lock1->li_flags & LI_EXCLUSIVE) != 0 && > (flags & LOP_EXCLUSIVE) == 0) { > printf("shared lock of (%s) %s @ %s:%d\n", > class->lc_name, lock->lo_name, file, line); > printf("while exclusively locked from %s:%d\n", > lock1->li_file, lock1->li_line); > panic("share->excl"); > } > if ((lock1->li_flags & LI_EXCLUSIVE) == 0 && > (flags & LOP_EXCLUSIVE) != 0) { > printf("exclusive lock of (%s) %s @ %s:%d\n", > class->lc_name, lock->lo_name, file, line); > printf("while share locked from %s:%d\n", > lock1->li_file, lock1->li_line); > panic("excl->share"); > } > return; > } > > Because of the return statement we do not seem to be doing any additional order > checking in the case of recursion. Correct. WITNESS has never done LOR checking on trylocks or recursive acquires since those will never block. -- John Baldwin