Hi!
> > Thread 1 is in kernel and holds lock A. You need lock A to dump state.
> > When you move 1 to phantom runqueue, you loose ability to get A and
> > deadlock.
> >
> > What prevents that?
>
> Any pending tasklet / bottom half + top half get processes by the real CPU's
> even thought the I/O bound process may have been moved to the phantom run
> queue. Its just that for the suspended processes sitting on the phantom
> queue this processing stops with the call to try_to_wake_up, until the
> process is moved back onto a run queue with a CPU.
>
> The only way I can see what your talking about happening is for some kernel
> code (or driver) to grab a lock and then hold it across a call to one of the
> sleep_on functions pending some I/O.
>
> Any driver that holds a lock across any sleep_on call I think is abusing
> locks and needs adjusting.
I do not think so. It is okay to grab a lock then sleep.
Pavel
-- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 23 2002 - 22:00:12 EST