>> interrupts being serviced while the page fault is in progress on x86 but not on ARM or did I miss something in my reading of the code?

Turns out I did miss something in my reading of the code. Interrupts are indeed disabled on x86 on entry into the page fault handler until we save the CR2 register (which holds the faulting address). Local IRQs are enabled in the fault handler after that. This prevents an interrupt (or maybe another thread too?) clobbering the CR2 value before the faulting address is saved.

However, this still leaves me with my original "guesses":

>> I would have guessed that (non-threaded) interrupts be disabled during page faults because of the possibility of a recursive lock acquire or stack overflow if the interrupt handler itself page faults.

I assume this is not a problem because we don't actually "handle" page faults that happen because of interrupts? Going off of this comment:

_If we're in an interrupt, have no user context or are running in a region with pagefaults disabled then we must not take the fault_

in arch/x86/mm/fault.c I does indeed look like that. I'd be glad if someone can clarify this.

Shrikant

On Tue, May 7, 2019, 10:19 AM Shrikant Giridhar <shrikantgiridhar@gmail.com> wrote:

Hi,

I was looking at arch code setting up page fault handling in the kernel and came away with a couple of questions.

Can hardware interrupts (non-NMI) occur during page faults? On x86, I notice that the page fault handler is set up with an interrupt gate which should clear the IF (Interrupt Enable) bit - disabling maskable interrupts in the process. I also don't see interrupts being enabled later in the handler (arch/x86/mm/fault.c:do_page_fault).

However, from a quick skim, it doesn't look like the same rule is followed on ARM (32-bit) where local IRQs are enabled after we enter the page fault handler (arch/arm/mm/fault.c:do_page_fault).

Is there a general policy for interrupt handling during page faults? I would have guessed that (non-threaded) interrupts be disabled during page faults because of the possibility of a recursive lock acquire or stack overflow if the interrupt handler itself page faults.

Is there an arch-specific factor involved which prevents (AFAICT) interrupts being serviced while the page fault is in progress on x86 but not on ARM or did I miss something in my reading of the code?

Shrikant