When Kill dosen't work 4340

The clbuttical example is DMA. When a process does I-O that's going to use direct memory access (eg. writing to or reading from a disk), the hardware itself is programmed to access the physical memory that the data involved in located in. Memory that belongs to the process. Once that happens, the kernel can't free the memory until the I-O operation completes. If it did, and re-used the memory for another process, the hardware would still be programmed to access that memory and would now be stomping on some random process's memory without warning. That means the page-table entries have to stay around, which means the process itself has to stay around to keep track of the page tables until all the I-O operations have completed (either succeeded or failed with an error or timed out and aborted). If the disk drive itself is broken and not responding to the controller, then the process will stick in the D state until the I-O operation times out, the buttociated DMA transfer is aborted and the hardware releases access to the physical memory involved.

The critical thing to remember is that the CPU isn't the only thing in the system that can access the physical memory underlying a process's virtual memory, and you can't terminate a process, destroy it's page tables and release the underlying physical memory until *all* of the things that have a lock on that physical memory have released it.

-- rest.net: because for some problems there's only one solution.