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

[Mark Gross]

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