[Linux Internals] My notes on: Signals, Interrupts, Exceptions, Traps.,etc

Quick note: Signals are between Kernel and process; Interrupts are between CPU and Kernel.

Signal is a message that may be sent to a process or group pf processes and only info sent to process is number identifying the signal.

Purpose:
- To make processes aware that some event has happened
- To make process execute signal handler code included in its code

Important characteristics:

• Signal can be sent at any time to a process and if its sent when process is not executing, it must be saved by kernel until process resumes execution.
  Signals generated, but not yet delivered are — “Pending signals”. At any time, ONLY ONE type of pending signal can exist for a process; any additional same type of pending signals are DISCARDED!.

Credit: Google images

• Signals can be sent between processes or between the kernel and a process
• 3 possible ways a process can respond: explicitly ignore the signal, execute the default action or catch the signal by invoking corresponding signal-handler function.
• How to list all the signals available in a specific OS: “kill -l”
• No actual data is being sent as part of signal; Its just a notification that an event has occurred

• Signals can be handled either by default handlers or user-processes can define their own handlers to handle them. There are exceptions : The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
  SIGKILL 9 Term Kill signal
SIGSTOP 17,19,23 Term suspends the process until you do a SIGCONT
• Please note that SIGSTOP and SIGTSTP are 2 different signals!

#define SIGSTOP     19  /* Stop, unblockable (POSIX).  */
#define SIGTSTP     20  /* Keyboard stop (POSIX). Ctrl+Z  */

List of signals used very often

• Signals delivery mechanism can be either synchronous or asynchronous
• trap command allows us to trap some or all of these signals, and perform operations on the trapped signals.

trap [options] [argument] [Signal specification]

#define SIGINT 2 /* Interactive attention signal. */
#define SIGILL 4 /* Illegal instruction. */
#define SIGABRT 6 /* Abnormal termination. */
#define SIGFPE 8 /* Erroneous arithmetic operation. */
#define SIGSEGV 11 /* Invalid access to storage. */
#define SIGTERM 15 /* Termination request. */

/* Historical signals specified by POSIX. */
#define SIGHUP 1 /* Hangup. */
#define SIGQUIT 3 /* Quit. */
#define SIGTRAP 5 /* Trace/breakpoint trap. */
#define SIGKILL 9 /* Killed. */
#define SIGBUS 10 /* Bus error. */
#define SIGSYS 12 /* Bad system call. */
#define SIGPIPE 13 /* Broken pipe. */
#define SIGALRM 14 /* Alarm clock. */

System calls involved

SIGINT, SIGTERM, SIGKILL (All for terminating a process !)

• SIGINT is intended as a signal sent by the user
• In general the processes communicate with each other using other signals. For ex: a parent process usually sends SIGTERM to its children to terminate them, even if SIGINT has the same effect.
• SIGQUIT generates a core dump which is useful for debugging.

SIGTERM is the preferred way as it terminates the process gracefully.

Interrupts

Interrupts vs Signals :

• Interrupts are initiated by CPU (SIGFPE, SIGSEGV, page fault) or CPU instructions(traps) or hardware devices (keyboard, mouse)
• CPU will then interrupt the current task and notify the kernel about the interrupt
• Hardware Interrupt: directly handled by Interrupt Handler
• Software Interrupt: kernel sends signal to the process; Signals may NOT be sent always sent in response to a software interrupt
• SIGCHLD signal is sent to a parent process when its child process terminates
• SIGINT is sent when either software interrupt occurs or by a external process

So, in nutshell, how all they look like ?

Image Source: Wikipedia

When you press or release a key, that event is signaled up the keyboard cable to raise a hardware interrupt. The keyboard sends signals on its interrupt request line (IRQ), which is mapped to an interrupt vector (integer) by the interrupt controller. The CPU uses the Interrupt Descriptor Table (IDT) to map the interrupt vectors to functions (interrupt handlers) which are supplied by the kernel. When an interrupt arrives, the CPU indexes the IDT with the interrupt vector and runs the appropriate handler. Thus, the kernel is entered.

As explained above, when an exception or interrupt occurs, execution transition from user mode to kernel mode where the exception or interrupt is handled.

While entering the kernel, the context (values of all CPU registers) of the currently executing process must first be saved to memory.

The kernel is now ready to handle the exception/interrupt.

1. Determine the cause of the exception/interrupt.
2. Handle the exception/interrupt.

When the exception/interrupt have been handled the kernel performs the following steps:

1. Select a process to restore and resume.
2. Restore the context of the selected process.
3. Resume execution of the selected process.