From owner-freebsd-arch@FreeBSD.ORG Thu Sep 1 12:51:01 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 772351065672; Thu, 1 Sep 2011 12:51:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 567218FC13; Thu, 1 Sep 2011 12:51:00 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02083; Thu, 01 Sep 2011 15:50:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E5F7FAE.20503@FreeBSD.org> Date: Thu, 01 Sep 2011 15:50:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Warner Losh , Hans Petter Selasky 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> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: John Baldwin , 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: Thu, 01 Sep 2011 12:51:01 -0000 on 31/08/2011 19:59 Warner Losh said the following: > 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" :) Yeah :-) In a sense that that particular code to which I referred is only called by *_poll routines in a few a drivers. And it's hard for me to imagine how a call from USB would go all the around to a poll routine and then back into USB. Or how a poll call into USB would get out of USB and back into the calling subsystem. Anyway, I think there could have been (or even - is) a legitimate reason to have that code. And I can really believe that that reason may have to do with our current state of panic(9) code where we do not stop other CPUs. I am glad with the reply from Hans that the code can be simplified. -- Andriy Gapon