Understanding the Linux Kernel

4.7. Returning from Interrupts and Exceptions

We will finish the chapter by examining the termination phase of interrupt and exception handlers. Although the main objective is clear, namely, to resume execution of some program, several issues must be considered before doing it:

• The number of kernel control paths being concurrently executed: if there is just one, the CPU must switch back to User Mode.

• Active bottom halves to be executed: if there are some, they must be executed.

• Pending process switch requests: if there is any request, the kernel must perform process scheduling; otherwise, control is returned to the current process.

• Pending signals: if a signal has been sent to the current process, it must be handled.

The kernel assembly language code that accomplishes all these things is not, technically speaking, a function, since control is never returned to the functions that invoke it. It is a piece of code with three different entry points called ret_from_intr, ret_from_sys_call, and ret_from_exception. We will refer to it as three different functions since this makes the description simpler. We shall thus refer quite often to the following three entry points as functions:

ret_from_intr( )

Terminates interrupt handlers

ret_from_sys_call( )

Terminates system calls, that is, kernel control paths engendered by 0x80 exceptions

ret_from_exception( )

Terminates all exceptions except the 0x80 ones

The general flow diagram with the corresponding three entry points is illustrated ...