panic: uhci_abort_xfer: not in process context

[Bernd Walter]

On Sat, Apr 02, 2005 at 07:02:18PM +0100, Ian Dowse wrote:
> 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.

Yes - you are right - my fault.
I missread the panic - in fact it is called from a callback, and I
somehow asumed that mtx_lock could release GIANT.
The panic is justified.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de