Kernel Newbies archive on lore.kernel.org
 help / Atom feed
* Interrupts during page fault exceptions
@ 2019-05-07 17:19 Shrikant Giridhar
  2019-05-07 18:31 ` Shrikant Giridhar
  0 siblings, 1 reply; 2+ messages in thread
From: Shrikant Giridhar @ 2019-05-07 17:19 UTC (permalink / raw)
  To: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2250 bytes --]

<div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Hi,</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I was looking at arch code setting up page fault handling in the kernel and came away with a couple of questions.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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&#39;t see interrupts being enabled later in the handler (arch/x86/mm/fault.c:do_page_fault).<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">However, from a quick skim, it doesn&#39;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).</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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?</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Shrikant<br></div></div></div>

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Interrupts during page fault exceptions
  2019-05-07 17:19 Interrupts during page fault exceptions Shrikant Giridhar
@ 2019-05-07 18:31 ` Shrikant Giridhar
  0 siblings, 0 replies; 2+ messages in thread
From: Shrikant Giridhar @ 2019-05-07 18:31 UTC (permalink / raw)
  To: kernelnewbies

[-- Attachment #1.1: Type: text/plain, Size: 2429 bytes --]

>> 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
>

[-- Attachment #1.2: Type: text/html, Size: 5559 bytes --]

<div dir="ltr"><div dir="ltr"><div dir="auto">&gt;&gt; <span style="font-family:arial,helvetica,sans-serif;font-size:12.8px">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?</span><div dir="auto"><span style="font-family:arial,helvetica,sans-serif;font-size:12.8px"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></span></span></div><div><span style="font-family:arial,helvetica,sans-serif;font-size:12.8px"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 <span style="font-family:arial,helvetica,sans-serif;font-size:12.8px"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">before the faulting address is saved. </span></span></span></span></div></div><div dir="auto"><br></div><div dir="auto"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">However, this still leaves me with my original &quot;guesses&quot;:</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">&gt;&gt;  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.</div></div><div dir="auto"><br></div><div dir="auto"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I assume this is not a problem because we don&#39;t actually &quot;handle&quot; page faults that happen because of interrupts? Going off of this comment:</div><br><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">_</span>If we&#39;re in an interrupt, have no user context or are running in a region with pagefaults disabled then we must not take the fault<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">_</span><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">in arch/x86/mm/fault.c I does indeed look like that. I&#39;d be glad if someone can clarify this.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Shrikant<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 7, 2019, 10:19 AM Shrikant Giridhar &lt;<a href="mailto:shrikantgiridhar@gmail.com" target="_blank">shrikantgiridhar@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Hi,</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I was looking at arch code setting up page fault handling in the kernel and came away with a couple of questions.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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&#39;t see interrupts being enabled later in the handler (arch/x86/mm/fault.c:do_page_fault).<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">However, from a quick skim, it doesn&#39;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).</div><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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?</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Shrikant<br></div></div></div>
</blockquote></div>

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-07 17:19 Interrupts during page fault exceptions Shrikant Giridhar
2019-05-07 18:31 ` Shrikant Giridhar

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org kernelnewbies@archiver.kernel.org
	public-inbox-index kernelnewbies


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/ public-inbox