Interrupts, Exceptions, and Traps

Three control-transfer mechanisms

The CPU transfers control to the kernel through three mechanisms, all of which ultimately lead to a kernel entry point via the interrupt descriptor table (IDT):

Mechanism	Trigger	Purpose
Interrupt	External hardware signal (e.g., disk completes I/O, timer fires)	Asynchronous notification of an event
Trap	Software instruction (syscall, int 0x80, svc)	Intentional request for kernel service
Exception	CPU detects an error during instruction execution (division by zero, page fault, invalid opcode)	Synchronous error handling

Interrupts are asynchronous — they are not caused by the currently running instruction. Traps and exceptions are synchronous — they are caused by the current instruction.

Interrupts in detail

An interrupt is a hardware signal that arrives on one of the CPU’s interrupt pins. The CPU checks for pending interrupts at the boundary between instructions (or at interruptible points during long instructions).

When an interrupt is accepted:

1. The CPU finishes the current instruction (or reaches an interruptible point).
2. It pushes the current program counter, the stack pointer, and the flags register onto the kernel stack.
3. It reads the interrupt vector from the interrupting device (or the interrupt controller, e.g., APIC).
4. It indexes the IDT with this vector to find the address of the Interrupt Service Routine (ISR).
5. It jumps to the ISR in kernel mode.

The ISR does the minimum possible work (acknowledge the interrupt, copy data from device registers, schedule a deferred bottom half) and returns. Interrupts remain disabled for the duration of the ISR unless the ISR explicitly re-enables them — long ISRs cause lost interrupts.

Exceptions in detail

An exception is the CPU’s response to a fault during instruction execution:

Type	Example	Behaviour
Fault	Page fault, alignment fault	The instruction can be restarted. The kernel fixes the problem (e.g., brings the page into memory) and resumes the instruction.
Trap	Breakpoint (int3), single-step	Used by debuggers. Control returns to the next instruction after the trap.
Abort	Machine check, double fault	Unrecoverable. The process is terminated or the system halts.

The interrupt-descriptor table (IDT)

The IDT is an array of 256 gate descriptors set up by the OS at boot time. Each entry specifies:

• The address (segment selector + offset) of the handler.
• The privilege level required to invoke it (some gates, like int3, are callable from user mode; most are kernel-only).
• The gate type (interrupt gate disables further interrupts; trap gate does not).

The LIDT instruction tells the CPU where the IDT lives.

Software interrupts and int instruction

The x86 int n instruction triggers a software interrupt. Historically, Linux used int 0x80 for system calls. This instruction is slower than syscall/sysenter (introduced with Pentium II/Athlon) because int must perform ring- and stack-switching logic in microcode. Modern kernels use syscall (x86-64) or sysenter (x86-32) for system calls, but int remains used for traps like breakpoints (int3).

Summary

• Interrupts are hardware-driven and asynchronous; traps and exceptions are software-driven and synchronous.
• All three use the IDT to vector to kernel handlers.
• ISRs must be short — defer work to bottom halves or kernel threads.
• Faults (like page faults) are fixable; aborts are not.
• syscall is the modern fast system-call mechanism, superseding the older int 0x80.