How are the signals handled in the kernel. What happens internally if I send a kill signal to a kernel thread/process. Does a crash in kernel process means kernel panic always, if not will it generate coredump.


1 Answer 1


When a thread is running code in kernel mode, signals are queued, i.e. the kernel remembers that a signal has been sent but doesn't act on it. When a kernel thread is waiting for an event, the wait may be interrupted by the signal — it's up to the author of the kernel code. For example, the Linux kernel API has pairs of functions like wait_event and wait_event_interruptible; only the “interruptible” function will return immediately if the thread receives a signal.

The reason kernel code isn't interrupted by signals is that it can put kernel memory or hardware devices in an inconsistent state. Therefore the code is always given a chance to clean things up.

Linux's kernel threads (i.e. threads of the kernel, listed with no corresponding executable in process lists) can't receive signals at all. More precisely, any signal delivered to a kernel thread is ignored.

A crash in kernel code may or may not cause a panic, depending on which part of the code caused the crash. Linux, for example, tries to recover from crashes in driver code, but whether this is possible depends on what went wrong. Crashes in kernel code may or may not generate a dump depending on the kernel and on the system configuration; for example Linux has a kernel crash dump mechanism.

  • You can also get signals to be queued in normal user processes (though it is optional). You can then use select, poll etc, to wait on them. Commented Apr 4, 2017 at 19:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .