Linux handling of exceptions and interrupts

1. Exception Handling

Linux uses exceptions to achieve two distinct purposes:

· Send a signal to the process to notify an anomalous situation

· Manage Hardware Resources < Br>

For the first case, for example, if the process performs a divide by 0 operation, the CPU will generate a <; division error & rdquo; exception, and the corresponding exception handler sends a SIGFPE to the current process signal. After the current process receives this signal, it takes a number of necessary steps to either recover from the error or terminate the execution (if there is no corresponding signal handler for this signal).

For the second case, the kernel uses two exceptions to efficiently manage hardware resources, and the corresponding handlers are more complicated. In this case, the exception does not indicate an error condition:

· Use the "Device Unavailable" exception to defer loading the floating point registers.

· Use “About page'; exception to postpone the new page frame to the process.

The kernel has a standard structure for the exception handler call, which consists of the following three parts:

· Saves the contents of most registers in the kernel stack (implemented in assembly language)

· Calling the exception handler written by C

· exits from the exception via the ret_from_exception() function.

The specific handling of exceptions in the kernel is not described in detail here. In Chapter 6, Memory Management, we will refer to the "pageout" exception handler. The focus of this section is on interrupt handling.

2. Interrupt Handling

When an interrupt occurs, not all operations have the same urgency. In fact, it is not appropriate to put all the operations into the interrupt handler itself. Long, non-critical operations that require a long time should be pushed back, because when an interrupt handler is running, the signal that is re-issued on the corresponding IRQ interrupt line is ignored. More importantly, the interrupt handler is executed on behalf of the process, and the process it represents must always be in the TASK_RUNNING state. Otherwise, system zombie may occur. Therefore, the interrupt handler cannot perform any blocking processes, such as I/O device operations. Therefore, Linux divides the operations to be performed by an interrupt into the following three categories:

(1) Critical (

such operations as interrupt controllers when an interrupt arrives Acknowledge, reprogram the interrupt controller or device controller, or modify the data structure accessed by both the device and the processor. These operations are urgent and should be performed very quickly, that is, emergency operations should be performed immediately within an interrupt handler, and the interrupt is disabled.

(2) Non-critical (Noncritical)

Such operations as modifying data structures that only the processor can access (for example, after scanning a key, read the scan code). These operations are also done very quickly, so they are executed immediately by the interrupt handler, but with interrupt enabled.

(3) Noncritical deferrable

This operation, for example, copies the contents of a buffer to the address space of some processes (for example, the keyboard line buffer) The content is sent to the process of the terminal handler). These operations may be delayed for longer intervals without affecting kernel operations: interested processes will wait for the required data. Non-emergency delayable operations are performed by a number of functions called "lower half" (bottom halves). We will discuss "lower part" in the following section.

All interrupt handlers perform four basic operations:

· Save the IRQ value and the contents of the register in the kernel stack.

· Sends an acknowledgment to the interrupt controller connected to the IRQ interrupt line, which will allow further interrupt requests to be issued on this interrupt line.

· Execute the Interrupt Service Routine (ISR) for all devices sharing this IRQ.

· Jumps to the address of ret_from_intr( ) and terminates.