Questions: Exception Handling: OS Internals

Question 1

A page fault occurs when the CPU tries to execute an instruction at virtual address X. After the OS handler loads the missing page from disk, execution resumes at...

• A. The instruction after address X, since the faulting instruction has already been attempted
• B. The entry point of the fault handler, to re-run the diagnostic logic
• C. Address X itself — the faulting instruction is retried
• D. The start of the current function, which must re-run from a clean state

Answer: (C)

A fault saves the address of the faulting instruction, not the next one. This is intentional: the instruction could not complete because a prerequisite (the page) was missing. Once the handler provides what was missing, it is correct to retry the exact same instruction — it will now succeed. If the CPU saved the next address instead, the faulting instruction would be silently skipped, producing incorrect behavior. This restart-on-fix design is what makes virtual memory and on-demand paging work transparently.

Question 2

A user program executes the 'syscall' instruction to request kernel services. What type of exception is this, and where does execution resume after the handler returns?

• A. A fault; execution restarts the syscall instruction so the request can be re-evaluated
• B. A trap; execution resumes at the instruction after the syscall
• C. An abort; the process is terminated as the hardware assumes the system call failed
• D. A hardware interrupt; execution resumes where it was interrupted, which may be anywhere

Answer: (B)

System calls are traps — intentional exceptions triggered after the instruction completes. The saved return address points to the next instruction because the syscall instruction itself has fully executed; the OS processes the request and returns to the instruction that follows. This is fundamentally different from a fault (which saves the current address for retry) and from an interrupt (which is asynchronous, triggered by external hardware rather than by the program itself).

Question 3

Exception handlers can run in user mode if the faulting process has sufficient privileges, allowing fast, OS-bypass handling.

• T. True
• F. False

Answer: False

Exception handlers always run in kernel mode, regardless of the privilege level of the code that triggered the exception. This is a hardware-enforced invariant, not an OS policy. When an exception occurs, the CPU unconditionally switches to kernel mode and loads the handler address from the interrupt descriptor table (IDT), which only the kernel can modify. This design ensures that a buggy user program cannot corrupt the OS or other processes — the kernel intercepts every fault and decides the response.

Question 4

A fault saves the instruction pointer to the address of the faulting instruction so that, after the handler resolves the problem, the same instruction can be retried.

• T. True
• F. False

Answer: True

This is the defining characteristic of a fault. A page fault is the canonical example: the instruction that accessed an unmapped virtual address is saved, the handler loads the needed page, and the CPU returns to execute that same instruction again. If faults saved the next instruction's address (as traps do), the faulting instruction would be skipped and the program would execute in a corrupt or incomplete state. The save-and-retry design makes transparent demand paging possible.

Question 5

What is the difference between a fault and a trap in terms of the saved return address, and why does this distinction matter for the correct behavior of virtual memory?

Model answer: A fault saves the address of the faulting instruction itself; a trap saves the address of the instruction that follows. For virtual memory, this distinction is essential: when a page fault occurs, the OS must be able to retry the exact instruction that caused the fault after loading the missing page. If it resumed at the next address, the memory access that triggered the fault would never complete, leaving the program in an undefined state. Traps (like system calls) don't need retrying because the triggering instruction has already completed its work before the exception is raised.

The saved address is the handler's return ticket. For faults, the problem exists because the instruction couldn't finish — fix the problem, restart the instruction. For traps, the instruction is finished — the OS does the requested service and moves on. This difference is why virtual memory works transparently: from the user program's perspective, accessing a paged-out address just takes a bit longer, with no visible effect, because the faulting instruction is silently retried after the page is loaded.