Every interrupt or exception gives rise to a kernel control path or separate sequence of instructions that
execute in Kernel Mode on behalf of the current process. For instance, when an I/O device raises an
interrupt, the first instructions of the corresponding kernel control path are those that save the contents of
the CPU registers in the Kernel Mode Stack, while the last are those that restore the contents of the
registers.
Kernel control path may be arbitrarily nested; an interrupt handler may be interrupted by another
interrupt handler, thus giving rise to a nested exectution of kernel control path, as shown in Figure 4-3.
As a result, the last instructions of a kernel control path that is taking care of an interrupt do not always
put the current process back into User Mode: if the level of nesting is greater than 1, these instructions
will put into execution the kernel control path that was interrupted last, and the CPU will continue to run
in Kernel Mode.
The price to pay for allowing nested kernel control path is that an interrupt handler must never block, that
is, no process switch can take place while an interrupt handler is running. In fact, all the data needed to
resume a nested kernel control path is stored in the Kernel Mode Stack, which is tightly bound to the current
process.
Assuming that the kernel is bug free, most exceptions can occur only while the CPU is in User Mode. Indeed,
they are either caused by programming errors or triggered by debuggers. However, the "Page Fault" exception
may occur in Kernel Mode. This happens when the process attempts to address a page that belongs to its address
space but is not currently in RAM. While handling such an exception, then kernel may suspend the current
process and replace it with another one until the requested page is available. The kernel control path that handles
the "Page Fault" exception resumes execution as soon as the process gets the processor again.
Because the "Page Fault" exception handler never gives rise to further exceptions, at most two kernel control
paths associated with exceptions (the first one caused by a system call invocation, the second one caused by
a Page Fault) may be stacked, one on top of the other.
In contrast to exceptions, interrupts issued by I/O devices do not refer to data structures specific to the current
process, although the kernel control paths that handle them run on behalf of that process. As a matter of fact, it
is impossible to predict which process will be running when a given interrupt occurs.
An interrupt handler may preempt both other interrupt handlers and exception handlers. Conversely, an exception
handler never preempts an interrupt handler. The only exception that can be triggered in Kernel Mode is "Page Fault",
which we just described. But interrupt handlers never perform operations that can induce page faults, and thus,
potentially a process switch.
Linux interleaves kernel control paths for two major reasons:
1. To improve the thoughput of programmable interrupt controllers and device controllers. Assume that a device controller
issues a signal on an IRQ line: the PIC transforms it into an external interrupt, and then both the PIC and the device
controller remain blocked until the PIC receives an acknowledgement from the CPU. Thanks to kernel control path interleaving,
the kernel is able to send the acknowledgement event when it is handling a previous interrupt. (???)
2. To implement an interrupt model without priority levels. Because each interrupt handler may be deferred by another one,
there is no need to establish predefined priorities among handware devices. This simplifies the kernel code and improves
its portability.
On multiprocessor systems, several kernel control paths may execute concurrently. Moreover, a kernel control path associated
with an exception may start executing on a CPU and, due to a process switch, migrate to another CPU.