Understanding the Linux Kernel, Second Edition

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:

Number of kernel control paths being concurrently executed

If there is just one, the CPU must switch back to User Mode.

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 is 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 four different entry points called ret_from_intr, ret_from_exception, ret_from_sys_call, and ret_from_fork. We will refer to it as four different functions since this makes the description simpler, and we shall refer quite often to the following three entry points as functions:

ret_from_exception( )

Terminates all exceptions except the 0x80 ones

ret_from_intr( )

Terminates interrupt handlers

ret_from_sys_call( )

Terminates system calls (i.e., kernel control paths engendered by 0x80 programmed exceptions)

ret_from_fork( )

Terminates the fork( ), vfork( ), or clone( ) system calls (child only).

The general flow diagram with the corresponding four entry points is ...