From: sashiko-bot@kernel.org
To: "Heiko Carstens" <hca@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 12/12] s390/percpu: Rework to simplify percpu_entry() and percpu_exit()
Date: Thu, 17 Sep 2026 19:42:59 +0000 [thread overview]
Message-ID: <20260917194259.7EF361F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917192237.638324-13-hca@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] s390/percpu: unconditional register fixup in percpu_exit() corrupts GPRs on NMI
--
commit 9424e4df4698f4a6dd024548cb15a93aae1331e4
Author: Heiko Carstens <hca@linux.ibm.com>
s390/percpu: Rework to simplify percpu_entry() and percpu_exit()
This commit changes s390 to implement a new approach for percpu code
sections similar to arm64, removing the need to check instruction opcodes
during interrupts. It encodes three register numbers into the
percpu_register field and uses a register pair to work around the
single-byte limit of the mviy instruction.
Link: https://lore.kernel.org/all/20260908151741.394589-1-mark.rutland@arm.com/
> diff --git a/arch/s390/include/asm/entry-percpu.h b/arch/s390/include/asm/entry-percpu.h
> index 89c9e44f6f833..7ec5d976db471 100644
> --- a/arch/s390/include/asm/entry-percpu.h
> +++ b/arch/s390/include/asm/entry-percpu.h
[ ... ]
> -static __always_inline void percpu_exit(struct pt_regs *regs, bool needs_fixup)
> +static __always_inline void percpu_exit(struct pt_regs *regs)
> {
> + unsigned char regval, regpcp, regoff, regptr;
> struct lowcore *lc = get_lowcore();
> - unsigned char reg;
>
> - if (user_mode(regs))
> - return;
> - reg = regs->percpu_register;
> - lc->percpu_register = reg;
> - if (likely(!needs_fixup))
> - return;
> - /* Check if process has been migrated to a different CPU. */
> - if (regs->cpu == lc->cpu_nr)
> + if (!regs->percpu_register)
> return;
> - /* Fixup percpu base register */
> - regs->gprs[reg] -= __per_cpu_offset[regs->cpu];
> - regs->gprs[reg] += lc->percpu_offset;
> + regval = regs->percpu_register;
> + lc->percpu_register = regval;
> + regpcp = FIELD_GET(PCPU_REG_PCP, regval);
> + regoff = FIELD_GET(PCPU_REG_OFF, regval);
> + regptr = regoff + 1;
> +
> + /*
> + * Update register 'regoff' which contains the current CPU's percpu
> + * offset, and recalculate and update current CPU's percpu variable
> + * address contained in register 'regptr'.
> + */
> + regs->gprs[regoff] = lc->percpu_offset;
> + regs->gprs[regptr] = regs->gprs[regpcp] + regs->gprs[regoff];
[Severity: High]
Does this unconditional fixup corrupt GPRs if an NMI interrupts the kernel
return path?
If a standard interrupt occurs during a percpu code section, the handler's
percpu_exit() restores the non-zero lc->percpu_register right before
returning to assembly. During the subsequent assembly return sequence (e.g.,
in .Lsysc_restore), lc->percpu_register remains non-zero.
If a non-migrating exception (such as a Machine Check NMI) hits during this
precise window, s390_do_machine_check() will save the return sequence's
current registers into pt_regs, call percpu_entry(), and then percpu_exit().
Because this patch removed the migration check (regs->cpu == lc->cpu_nr),
percpu_exit() now unconditionally overwrites the regoff and regptr GPRs.
Since the compiler's "=&d" constraint can allocate register pairs heavily
used by the return sequence (like %r10/%r11 where %r11 points to pt_regs,
or %r14/%r15 where %r15 is the stack pointer), the NMI will clobber them.
When the NMI returns, the interrupted return sequence continues with
corrupted GPRs, potentially causing fatal faults on instructions like
lmg %r0,%r15,__PT_R0(%r11).
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260917192237.638324-1-hca@linux.ibm.com?part=12
prev parent reply other threads:[~2026-09-17 19:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 19:22 [PATCH 00/12] s390: More this_cpu_*() changes Heiko Carstens
2026-09-17 19:22 ` [PATCH 01/12] s390/percpu: Fix comment typo Heiko Carstens
2026-09-17 19:24 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 02/12] s390/percpu: Add sanity check to GEN_MVIY macro Heiko Carstens
2026-09-17 19:26 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 03/12] s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS Heiko Carstens
2026-09-17 19:29 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 04/12] s390/percpu: Let MVIY_PERCPU() calculate alternative displacement Heiko Carstens
2026-09-17 19:29 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 05/12] s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines Heiko Carstens
2026-09-17 19:27 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 06/12] s390/percpu: Rename inline assembly symbolic names Heiko Carstens
2026-09-17 19:25 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 07/12] s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies Heiko Carstens
2026-09-17 19:26 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 08/12] s390/percpu: Use percpu code section for this_cpu_cmpxchg128() Heiko Carstens
2026-09-17 19:29 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 09/12] s390/percpu: Use percpu code section for this_cpu_xchg() Heiko Carstens
2026-09-17 19:30 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 10/12] s390/percpu: Use percpu code section for this_cpu_cmpxchg() Heiko Carstens
2026-09-17 19:31 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 11/12] s390: Add CC_HAS_ASM_M_FORMAT_FLAG config option Heiko Carstens
2026-09-17 19:32 ` sashiko-bot
2026-09-17 19:22 ` [PATCH 12/12] s390/percpu: Rework to simplify percpu_entry() and percpu_exit() Heiko Carstens
2026-09-17 19:42 ` sashiko-bot [this message]
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=20260917194259.7EF361F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.