panic: uhci_abort_xfer: not in process context

[Ian Dowse]

In message <20050402171938.GU2072 at cicely12.cicely.de>, Bernd Walter writes:
>I fully agree with you - in general.
>You see the inetrrupt routine as non-blocking context.
>Fine - abort_xfer is bad as it blocks for a long time - agreed.
>But we need any kind of syncronisation with top half.
>Although taking a mutex may block I don't consider it bad as it should
>not be hold for long time and therefor waiting a long time is unlikely.
>Allowing to wait for a Mutex in the bottom half is the whole reason we
>have interrupt threads.
>But that is the current problem - we are not even allowed to take
>a Mutex, just because intr_context isn't safe.
>The panic was triggered by a userland call that was claimed to be in
>interrupt context.
>OK - I was wrong in that it was not close, but that doesn't change
>anything with the basic problem:
>The panic triggered when it shouldn't.

Maybe I'm misunderstanding the cause of some of these panics, so
correct me if this sounds wrong. There seem to be two ways for the
"not in process context" panic to occur. One is where usbd_abort_pipe()
is called directly from an interrupt thread. The other way is for
a callback to be called from interrupt thread and that callback
sleeps. This allows other threads to enter the USB code with
intr_context > 0, so the panic can be incorrectly triggered.

In both cases, the bug is that a callback function is sleeping and
allowing other threads to run. I'm not sure I understand your
comments about locking mutexes though. It is fine for a callback
function to acquire a mutex, because acquiring a mutex is not really
sleeping, because currently held locks are not dropped even if the
mutex cannot be acquired immediately. For example, the USB system
will hold Giant at the time that the interrupt thread is calling
completion callbacks. Even if one of those callbacks needs to acquire
another mutex that is currently locked, Giant will not be dropped
while that mutex is acquired, so no other threads can enter the USB
code. The problem is limited to tsleep/msleep where all mutexes are
dropped.

A more specific statement of the original comments would be that
callbacks in asynchronous event systems should not call tsleep or
msleep, no matter what the calling context is.

Ian