USB/coredump hangs in 8 and 9

[Andriy Gapon]

on 20/08/2011 16:35 Hans Petter Selasky said the following:
> On Friday 19 August 2011 18:32:13 Andriy Gapon wrote:
>> on 19/08/2011 00:24 Hans Petter Selasky said the following:
>>> On Thursday 18 August 2011 19:04:10 Andriy Gapon wrote:
>>>> If you can help Hans to figure out what you is wrong with USB subsystem
>>>> in this respect that would help us all.
>>>
>>> Hi,
>>>
>>> usb_busdma.c:   /* we use "mtx_owned()" instead of this function */
>>> usb_busdma.c:   owned = mtx_owned(uptag->mtx);
>>> usb_compat_linux.c:     do_unlock = mtx_owned(&Giant) ? 0 : 1;
>>> usb_compat_linux.c:     do_unlock = mtx_owned(&Giant) ? 0 : 1;
>>> usb_compat_linux.c:     do_unlock = mtx_owned(&Giant) ? 0 : 1;
>>> usb_hub.c:      if (mtx_owned(&bus->bus_mtx)) {
>>> usb_transfer.c: if (!mtx_owned(info->xfer_mtx)) {
>>> usb_transfer.c: if (mtx_owned(xfer->xroot->xfer_mtx)) {
>>> usb_transfer.c:         while (mtx_owned(&xroot->udev->bus->bus_mtx)) {
>>> usb_transfer.c:         while (mtx_owned(xroot->xfer_mtx)) {
>>
>>> One fix you will need to do, if mtx_owned is not giving correct value is:
>> First, could you please clarify what is the correct, or rather - expected,
>> value in this case.  It's not immediately clear to me if we should
>> consider all locks as owned or un-owned in a situation where all locks are
>> actually skipped behind the scenes.
>> Maybe USB code should explicitly check for that condition as to not make
>> any unsafe assumptions.
>>
>> Second, it's not clear to me what the above list actually represents in the
>> context of this discussion.
> 
> Hi,
> 
> The mtx_owned() is not only used to assert mutex ownership, but also to figure 
> out which context the function is being called from. If the correct mutex is 
> not locked already we postpone the work until later. In the panic case, there 
> is no way to postpone work, so this check should be skipped in case of panic, 
> because there is no other thread to put work to.

Now I see, but still I can not make the conclusions...
So what would you suggest - should USB code explicitly check for panicstr (or
SCHEDULER_STOPPED in the future)?  Or what mutex_owned should return - true or
false?

-- 
Andriy Gapon