Date: Thu, 01 Sep 2011 15:50:54 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, Hans Petter Selasky <hselasky@FreeBSD.org> Cc: John Baldwin <jhb@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb Message-ID: <4E5F7FAE.20503@FreeBSD.org> In-Reply-To: <B230DCD7-E21F-4B66-9ECE-B759BEBBB749@bsdimp.com> References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> <201108310943.24476.jhb@freebsd.org> <4E5E5DA0.4060003@FreeBSD.org> <DD9206EC-A969-434A-ABC5-15B2857C571C@bsdimp.com> <4E5E655E.8060505@FreeBSD.org> <B230DCD7-E21F-4B66-9ECE-B759BEBBB749@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E5F7FAE.20503>