Re: killall -9 does not work !?

From: Albert D. Cahalan (
Date: Wed May 24 2000 - 14:43:26 EST

Jesse Pollard writes:
> On Tue, 23 May 2000, Albert D. Cahalan wrote:
>> Jesse Pollard writes:

>>> It depends, in part, on the ability to abort a controller+device
>>> in the middle of I/O, determine if the I/O is part of the desired
>>> "rundown" or resume the transaction. This is a serious problem
>> No, the process could be killed. Depending on the hardware, one
>> might get stuck with a bit of garbage to be collected later.
>> Basically you just free all unrelated resources, then declare
>> the process to be dead and buried.
>> Note: using "device" to mean something physical
>> So you have 1000 pages of memory, with 20 being actively written
>> to by a device doing DMA. Fine, free the other 980 pages.
>> The device doesn't even know what a PID is, so reclaim that too.
>> Devices don't know about file descripters, so free those. Etc.
> This is called a memory leak...

How is an unkillable process not a memory leak? The leak is
already there; one can at least reduce it a bit.

> And you can crash some systems
> with it, especially those with devices with limited address DMA.

Bummer. You can crash Linux by filling all process table slots
with unkillable processes.

> It is also larger than 20 pages --- the buffer headers have to be
> saved, the dma request descriptions have to be saved, and other
> lists needed so that the driver can release the memory when the
> DMA does complete (and figure out what to do for network devices...).
> You also get a problem when the DMA completes - what process is it
> that gets a wakeup (though this should be able to be handled).

No big deal. I don't see why you'd want to leak the extra 980
pages when you can leak only 20 (plus overhead) instead.
The 20 are lost... might as well recover the rest.
Garbage collection is nice, but it isn't a requirement.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:12 EST