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