>>>>> "Guenther" == Guenther Grau <s_grau@ira.uka.de> writes:

    Guenther> Hi, I think I know quite a bit about Unix-internals, but
    Guenther> I was never really able to figure out why it is
    Guenther> _neccessary_ to have a process in a state in which it
    Guenther> cannot be delivered a SIGKILL. Can anybody clue me in on
    Guenther> that one?  I know that this usually happens when a
    Guenther> process is waiting for 'fast' i/o, but why is it really
    Guenther> needed, or this this just an optimization. IMHO, it
    Guenther> should always be possible to remove a process from a
    Guenther> system, regardless what the process is just doing.

Processes that are in the busy wait state (ie waiting at a priority
above PZERO) are usually waiting for "fast" I/O. As such, they will
acquire and lock critical kernel resources - say a disk buffer or an
inode. If these are not unlocked properly - say because the process
was summarily killed - the resources become unavailable to the rest of
the system. Repeat this often enough and you end up with an inode
table filled with locked inodes that nobody is using and can't be
discarded easily. (OK, NetBSD doesn't have an inode table any more,
but the example illustrates the point.)

Depleting the buffer pool (or locking out vnodes/inodes) is bad
enough, but it can get worse. If the process was performing raw
disk/tape I/O, it will probably use the buf struct for the head of the
drive's I/O queue. With that locked, nobody else can add or remove I/O
requests from the device's queue. The consequences of that should not
require futher explanation.