From: "Kiryl Shutsemau (Meta)" <kas@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
James Morse <james.morse@arm.com>
Cc: "Kiryl Shutsemau (Meta)" <kas@kernel.org>,
Marc Zyngier <maz@kernel.org>,
Doug Anderson <dianders@chromium.org>,
Usama Arif <usama.arif@linux.dev>,
Breno Leitao <leitao@debian.org>, Dawei Li <dawei.li@linux.dev>,
mrigendrachaubey <mrigendra.chaubey@gmail.com>,
kernel-team@meta.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH 1/2] arm64: sdei: Run the event handler on the kernel vectors
Date: Wed, 4 Nov 2026 18:09:33 +0000 [thread overview]
Message-ID: <20261104180936.2981070-2-kas@kernel.org> (raw)
In-Reply-To: <20261104180936.2981070-1-kas@kernel.org>
With KPTI, VBAR_EL1 holds the trampoline vectors from the return to EL0
until the next exception from EL0 maps the kernel and installs the
kernel vectors. The trampoline vectors only handle exceptions from EL0;
their current-EL half is zero-filled.
An SDEI event is dispatched regardless of PSTATE.DAIF, so it lands there
whenever the CPU is in user space. The SDEI entry trampoline maps the
kernel but leaves VBAR_EL1 alone. An exception taken by the handler then
executes the zeros, takes an undefined instruction exception to the same
vector, and loops there forever. The event never completes and the CPU
is lost; RCU stall reports are the first sign of it.
RAS notifications land in user space whenever a task consumes the
error, and NMI backtraces land wherever the CPU happens to be. The GHES
handler takes no exception on its own, but any exception in the handler
path does it: a WARN, a kprobe hit, or a fault fixed up by a _nofault()
accessor.
Install the kernel vectors in do_sdei_event() when VBAR_EL1 holds the
trampoline vectors, and restore it before returning to firmware,
including when the handler fails. The IRQ-like resume into user space
keeps using the interrupted value, as it must go through the trampoline
to map the kernel.
Fixes: 79e9aa59dc29 ("arm64: sdei: Add trampoline code for remapping the kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
---
arch/arm64/kernel/sdei.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c
index 778f2a1faac8..9fa2a3aeed48 100644
--- a/arch/arm64/kernel/sdei.c
+++ b/arch/arm64/kernel/sdei.c
@@ -18,6 +18,7 @@
#include <asm/sections.h>
#include <asm/stacktrace.h>
#include <asm/sysreg.h>
+#include <asm/vectors.h>
#include <asm/vmap_stack.h>
unsigned long sdei_exit_mode;
@@ -214,6 +215,20 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs,
if (arm64_kernel_unmapped_at_el0())
clobbered_registers++;
+ /*
+ * With KPTI, VBAR_EL1 holds the trampoline vectors from the return to
+ * EL0 until the next exception from EL0 maps the kernel. They only
+ * handle exceptions from EL0: an exception taken by the handler would
+ * run their empty current-EL half and never come back. Run the handler
+ * on the kernel vectors. The IRQ-like resume below keeps using the
+ * interrupted VBAR, so it still goes through the trampoline.
+ */
+ if (arm64_kernel_unmapped_at_el0() &&
+ vbar == (unsigned long)this_cpu_read(this_cpu_vector)) {
+ write_sysreg((unsigned long)vectors, vbar_el1);
+ isb();
+ }
+
/* Retrieve the missing registers values */
for (i = 0; i < clobbered_registers; i++) {
/* from within the handler, this call always succeeds */
@@ -221,8 +236,6 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs,
}
err = sdei_event_handler(regs, arg);
- if (err)
- return SDEI_EV_FAILED;
if (elr != read_sysreg(elr_el1)) {
/*
@@ -233,6 +246,11 @@ unsigned long __kprobes do_sdei_event(struct pt_regs *regs,
pr_warn("unsafe: exception during handler\n");
}
+ write_sysreg(vbar, vbar_el1);
+
+ if (err)
+ return SDEI_EV_FAILED;
+
mode = regs->pstate & (PSR_MODE32_BIT | PSR_MODE_MASK);
/*
--
2.54.0
next prev parent reply other threads:[~2026-11-04 18:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 18:09 [PATCH 0/2] arm64: sdei: Handle exceptions taken inside the event handler Kiryl Shutsemau (Meta)
2026-11-04 18:09 ` Kiryl Shutsemau (Meta) [this message]
2026-11-04 18:28 ` [PATCH 1/2] arm64: sdei: Run the event handler on the kernel vectors Usama Arif
2026-11-04 18:09 ` [PATCH 2/2] arm64: sdei: Preserve the interrupted context's exception registers Kiryl Shutsemau (Meta)
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=20261104180936.2981070-2-kas@kernel.org \
--to=kas@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dawei.li@linux.dev \
--cc=dianders@chromium.org \
--cc=james.morse@arm.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mrigendra.chaubey@gmail.com \
--cc=stable@vger.kernel.org \
--cc=usama.arif@linux.dev \
--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
all inboxes | Powered by JetHome®