SIGKILL and a sleeping kernel module

[Valdis.Kletnieks at vt.edu]

On Tue, 19 Feb 2013 10:37:28 +0200, Kevin Wilson said:
> Hi all,
> I am trying to send a SIGKILL to a kernel module which is sleeping.
> I added a printk after the sleep command.
> Sending a SIGLKILL (by kill -9 SIGLKILL pidOfKernelThread) does **not**
> yield the message from printk("calling do_exit\n");
>  which is immediately after the msleep() command, as I expected.

Others have mentioned the various types of sleeping in the kernel, but
overlooked a minor detail.  If a task is in the kernel in a non-interruptible
state, signals are queued and delivered once that status is cleared (which
often doesn't happen until a syscall is about to return to userspace).

The reason this detail is important for would-be kernel hackers:

If one kernel thread manages to BUG() or oops() or otherwise die
or wedge up while holding a lock, other processes can end up blocking
while waiting for the lock.  The problem is that the other processes are
usually in non-interruptible state when they try to take the lock.  The
end result is that you end up with processes that are blocked in the
kernel, and you can't kill -9 them - you're basically stuck with them
until you reboot.  This is why your system will often limp along and
slowly become more and more wedged up after a BUG().

Also - the fact that /bin/ps shows a D or S does *not* in fact mean the
process is in a sleep state inside the kernel.  That's *usually* the case,
but it's quite possible for the code to be actively executing and burning
lots of CPU (often because it's stuck in a loop that's failing to make
forward progress).  The result there is that ps shows a D/S but your
CPU starts getting *very* warm....



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130219/7ecb86c2/attachment.bin