Messages in this thread | | | From | Mark Gross <> | Subject | Re: PATCH Multithreaded core dump support for the 2.5.14 (and 15) kernel. | Date | Wed, 15 May 2002 16:53:18 -0400 |
| |
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 - 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/
| |