Date: Sat, 20 Aug 2011 19:45:57 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-stable@FreeBSD.org Subject: Re: USB/coredump hangs in 8 and 9 Message-ID: <4E4FE4C5.9030305@FreeBSD.org> In-Reply-To: <201108201535.24061.hselasky@c2i.net> References: <DA1FD6FD-2E57-4EC4-899D-2C1CBB769456@averesystems.com> <201108182324.58276.hselasky@c2i.net> <4E4E900D.8010506@FreeBSD.org> <201108201535.24061.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4FE4C5.9030305>