skipping locks, mutex_owned, usb

Andriy Gapon avg at
Thu Sep 1 12:51:01 UTC 2011

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

More information about the freebsd-arch mailing list