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.
Linux Kernel – How Signals are Handled
kernellinuxsignals
Related Solutions
In addition to processes calling kill(2), some signals are sent by the kernel (or sometimes by the process itself) in various circumstances:
- Terminal drivers send signals corresponding to various events:
- Key press notifications:
SIGINT(please go back to the main loop) on Ctrl+C,SIGQUIT(please quit immediately) on Ctrl+\,SIGTSTP(please suspend) on Ctrl+Z. The keys can be changed with thesttycommand. SIGTTINandSIGTTOUare sent when a background process tries to read or write to its controlling terminal.SIGWINCHis sent to signal that the size of the terminal window has changed.SIGHUPis sent to signal that the terminal has disappeared (historically because your modem had hung up, nowadays usually because you've closed the terminal emulator window).
- Key press notifications:
- Some processor traps can generate a signal. The details are architecture and system dependent; here are typical examples:
- A number of signals notify the target process that some system event has occured:
SIGALRMnotifies that a timer set by the process has expired. Timers can be set withalarm,setitimerand others.SIGCHLDnotifies a process that one of its children has died.SIGPIPEis generated when a process tries to write to a pipe when the reading end has been closed (the idea is that if you runfoo | barandbarexits,foogets killed by aSIGPIPE).SIGPOLL(also calledSIGIO) notifies the process that a pollable event has occured. POSIX specifies pollable events registered through theI_SETSIGioctl. Many systems allow pollable events on any file descriptor, set via theO_ASYNCfcntlflag. A related signal isSIGURG, which notifies of urgent data on a device (registered via theI_SETSIGioctl) or socket.- On some systems,
SIGPWRis sent to all processes when the UPS signals that a power failure is imminent.
These lists are not exhaustive. Standard signals are defined in signal.h.
Most signals can be caught and handled (or ignored) by the application. The only two portable signals that cannot be caught are SIGKILL (just die) and STOP (stop execution).
SIGSEGV (segmentation fault) and its cousin SIGBUS (bus error) can be caught, but it's a bad idea unless you really know what you're doing. A common application for catching them is printing a stack trace or other debug information. A more advanced application is to implement some kind of in-process memory management, or to trap bad instructions in virtual machine engines.
Finally, let me mention something that isn't a signal. When you press Ctrl+D at the beginning of a line in a program that's reading input from the terminal, this tells the program that the end of the input file is reached. This isn't a signal: it's transmitted via the input/output API. Like Ctrl+C and friends, the key can be configured with stty.
This is (somewhat) undefined.
If the receiving process is set up to take action upon receipt of the signal (that is, the signal is not ignored or blocked, then the process becomes runnable. If it has sufficient priority, then it is also scheduled immediately, but that is not guaranteed.
Best Answer
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_eventandwait_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.