skipping locks, mutex_owned, usb

[Warner Losh]

On Aug 31, 2011, at 10:46 AM, Andriy Gapon wrote:

> on 31/08/2011 19:32 Warner Losh said the following:
>> 
>> 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?
>>> 
>>> 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...
>> 
>> 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.
> 
> 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