From owner-freebsd-arch@FreeBSD.ORG Wed Aug 31 17:13:58 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 E17271065676; Wed, 31 Aug 2011 17:13:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 80F688FC0C; Wed, 31 Aug 2011 17:13:58 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p7VGxLtQ082917 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 10:59:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E5E655E.8060505@FreeBSD.org> Date: Wed, 31 Aug 2011 10:59:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> <4E5E655E.8060505@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 31 Aug 2011 10:59:26 -0600 (MDT) Cc: Hans Petter Selasky , freebsd-arch@freebsd.org 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: Wed, 31 Aug 2011 17:13:59 -0000 On Aug 31, 2011, at 10:46 AM, Andriy Gapon wrote: > on 31/08/2011 19:32 Warner Losh said the following: >>=20 >> On Aug 31, 2011, at 10:13 AM, Andriy Gapon wrote: >>> So why the mutex unwinding/rewinding code is present at all? >>> What kind of situations is it supposed to prevent? >>>=20 >>> Personally I think that we either know that those drivers should not = hold the >>> locks in question (bus_mtx and xfer_mtx) or we know that they hold = them. >>> I do not see why we have to be conditional here or have a loop = even... >>=20 >> Today, I think we know these things. In the past, as the code was = written, there was a lot more special case code needed for giant = cohabitation. >=20 > Since you chimed in... :-) > I have a hard time imagining a situation where that code is useful = today or was > useful before. > Any example, purely hypothetical even, would do. IIRC, and Hans can correct me, this code was put in so that we could run = GIANT locked usb network drivers (or was it TTY drivers). There were = situations where the USB would have a lock held, then need to call into = code that picked up GIANT which then called back into the USB stack = which then would pick up GIANT and make calls to routines to pickup the = USB lock, and fail due to recursion (or was that to prevent a witness = warning about sleeping with malloc, it has been a while and I don't = recall for sure). I'm sure I'm forgetting a detail or two because = re-reading what I just wrote makes me go "what, that doesn't sound quite = right" :) Today, the locking landscape is such that I don't think we still have = the same issues. However, I've not studied the USB code recently, so = hopefully Hans can help sort out the reasons for it. Warner