Re: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel.

Mark Gross
2002-05-15T23:54:47Z

On Wednesday 15 May 2002 10:04 am, Pavel Machek wrote:
> Okay, what about:
>
> 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.

Nothing prevents someone writing a driver that abuses locks.

If you know of such a case I need to worry about or there is another way for
this design to get into trouble please let me know. I'll look into it as
quickly as I can.

--mgross