Page fault in Interrupt context

Can a page fault occur in an interrup开发者_Python百科t handler/atomic context ?

---

It can, but it would be a disaster. :-)

---

(This is an oldish question. The existing answers contain correct facts, but are quite thin. I will attempt to answer it in a more substantial way.)

The answer to this question depends upon whether the code is in the kernel (supervisor mode), or in user mode. The reason is that the rules for memory access in these regions are usually different. Here is a brief sequence of events to illustrate the problem (assuming kernel memory could be paged out):

1. While a user program is executing, an interrupt occurs (e.g. key press / disk event).
2. CPU transitions to supervisor mode and begins executing the handler in the kernel.
3. The interrupt handler begins to save the CPU state (so that the user process can be correctly resumed later), but in doing so it touches some of its storage which had previously been paged out.
4. This triggers a page fault exception.
5. In order to process the page fault exception, the kernel must now save the CPU state of the code that experienced the page miss.
6. It may actually be able to do this if it has a preallocated pool of memory that will never be paged out, but such a pool would be inevitably be limited in size.

So you see, the safest (and simplest) solution is for the kernel to ensure that memory owned by the kernel is not pagable at all. For this reason, page faults should not really occur within the kernel. They can occur, but as @adobriyan notes, that usually indicates a much bigger error than a simple need to page in some memory. (I believe this is the case in Linux. Check your specific OS to be sure whether kernel memory is non-pagable. OS architectures do differ.)

So in summary, kernel memory is usually not pagable, and since interrupts are usually handled within the kernel, page faults should not in general occur while servicing interrupts. Higher priority interrupts can still interrupt lower ones. It is just that all their resources are kept in physical memory.

The question about atomic contexts is less clear. If by that you mean atomic operations supported by the hardware, then no interrupt occurs within a partial completion of the operation. If you are instead referring to something like a critical section, then remember that critical sections only emulate atomicity. From the perspective of the hardware there is nothing special about such code except for the entry and exit code, which may use true hardware atomic operations. The code in between is normal code, and subject to being interrupted.

I hope this provides a useful response to this question, as I also wondered about this issue for a while.

---

Yes.

The code for the handler or critical region could span the boundary between two pages. If the second page is not available, then a page fault is necessary to bring it in.

---

Not sure why no body has used the word "Double Fault":

http://en.wikipedia.org/wiki/Double_fault

But that is the terms used in Intel manual:

http://software.intel.com/en-us/articles/introduction-to-pc-architecture/

or here:

ftp://download.intel.com/design/processor/manuals/253668.pdf (look at section 6-38).

There is something called triple fault too, which as the name indicate, can also happened when the CPU is trying to service the double fault error.

---

I think the answer is YES. I just checked the page fault handler code in kernel 4.15 for x86_64 platform. Take the following as a hint. no_context is the classic 'kernel oops'.

no_context(struct pt_regs *regs, unsigned long error_code,
           unsigned long address, int signal, int si_code)
{

        /* Are we prepared to handle this kernel fault? */
        if (fixup_exception(regs, X86_TRAP_PF)) {
                /*
                 * Any interrupt that takes a fault gets the fixup. This makes
                 * the below recursive fault logic only apply to a faults from
                 * task context.
                 */
                if (in_interrupt())
                        return;