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....
Attachment:
pgpOk2kstEKJW.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
