From: Peter Zijlstra <peterz@infradead.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, ada.coupriediaz@arm.com,
catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
luto@kernel.org, ruanjinjie@huawei.com, tglx@kernel.org,
vladimir.murzin@arm.com, will@kernel.org
Subject: Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
Date: Fri, 20 Mar 2026 14:04:33 +0100 [thread overview]
Message-ID: <20260320130433.GV3738786@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260320113026.3219620-2-mark.rutland@arm.com>
On Fri, Mar 20, 2026 at 11:30:25AM +0000, Mark Rutland wrote:
> Thomas, Peter, I have a couple of things I'd like to check:
>
> (1) The generic irq entry code will preempt from any exception (e.g. a
> synchronous fault) where interrupts were unmasked in the original
> context. Is that intentional/necessary, or was that just the way the
> x86 code happened to be implemented?
>
> I assume that it'd be fine if arm64 only preempted from true
> interrupts, but if that was intentional/necessary I can go rework
> this.
So NMI-from-kernel must not trigger resched IIRC. There is some code
that relies on this somewhere. And on x86 many of those synchronous
exceptions are marked as NMI, since they can happen with IRQs disabled
inside locks etc.
But for the rest I don't think we care particularly. Notably page-fault
will already schedule itself when possible (faults leading to IO and
blocking).
> (2) The generic irq entry code only preempts when RCU was watching in
> the original context. IIUC that's just to avoid preempting from the
> idle thread. Is it functionally necessary to avoid that, or is that
> just an optimization?
>
> I'm asking because historically arm64 didn't check that, and I
> haven't bothered checking here. I don't know whether we have a
> latent functional bug.
Like I told you on IRC, I *think* this is just an optimization, since if
you hit idle, the idle loop will take care of scheduling. But I can't
quite remember the details here, and wish we'd have written a sensible
comment at that spot.
Other places where RCU isn't watching are userspace and KVM. The first
isn't relevant because this is return-to-kernel, and the second I'm not
sure about.
Thomas, can you remember?
next prev parent reply other threads:[~2026-03-20 13:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 11:30 [PATCH 0/2] arm64/entry: Fix involuntary preemption exception masking Mark Rutland
2026-03-20 11:30 ` [PATCH 1/2] " Mark Rutland
2026-03-20 13:04 ` Peter Zijlstra [this message]
2026-03-20 14:11 ` Thomas Gleixner
2026-03-20 14:57 ` Mark Rutland
2026-03-20 15:34 ` Peter Zijlstra
2026-03-20 16:16 ` Mark Rutland
2026-03-20 15:50 ` Thomas Gleixner
2026-03-23 17:21 ` Mark Rutland
2026-03-20 14:59 ` Thomas Gleixner
2026-03-20 15:37 ` Mark Rutland
2026-03-20 16:26 ` Thomas Gleixner
2026-03-20 17:31 ` Mark Rutland
2026-03-21 23:25 ` Thomas Gleixner
2026-03-24 12:19 ` Thomas Gleixner
2026-03-25 11:03 ` Mark Rutland
2026-03-25 15:46 ` Thomas Gleixner
2026-03-26 8:56 ` Jinjie Ruan
2026-03-26 18:11 ` Mark Rutland
2026-03-26 18:32 ` Thomas Gleixner
2026-03-27 1:27 ` Jinjie Ruan
2026-03-26 8:52 ` Jinjie Ruan
2026-03-24 3:14 ` Jinjie Ruan
2026-03-24 10:51 ` Mark Rutland
2026-03-20 11:30 ` [PATCH 2/2] arm64/entry: Remove arch_irqentry_exit_need_resched() Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260320130433.GV3738786@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ada.coupriediaz@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=ruanjinjie@huawei.com \
--cc=tglx@kernel.org \
--cc=vladimir.murzin@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox