From: Heiko Carstens <hca@linux.ibm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Mete Durlu <meted@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Juergen Christ <jchrist@linux.ibm.com>,
Ilya Leoshkevich <iii@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v2 00/12] s390: More this_cpu_*() changes
Date: Fri, 18 Sep 2026 12:59:22 +0200 [thread overview]
Message-ID: <20260918105922.20386E38-hca@linux.ibm.com> (raw)
In-Reply-To: <aq0S_fKqcZ5WoLUU@J2N7QTR9R3>
On Fri, Sep 18, 2026 at 11:31:25AM +0100, Mark Rutland wrote:
> > v2:
> > - Yet another brown paper bug: Re-add CPU migration check to last
> > patch. Unconditionally recalculating and updating the percpu variable
> > address and percpu offset register can corrupt previous context
> > register state in several cases (not only the single case reported by
> > Sashiko).
>
> Do all of those case boil down to:
>
> * During exception entry from context A to context B, a nested exception
> is taken from context B to context C before percpu_entry() is called,
> and the nested exception handler updates B's live regs using A's
> percpu register indices.
>
> * During exception return from context B to context A, a nested
> exception is taken from context B to context C after percpu_entry() is
^^^^^^^^^^^^
That should have been percpu_exit(), I guess.
> called, and the nested exception handler updates B's live regs using
> A's percpu register indices.
>
> ... or was there another case that you spotted (e.g. some case where
> percpu_{entry,exit}() aren't called)?
Yes, all scenarios boil down to exactly the above.
> On arm64, I think we avoid those two cases by virtue of not taking
> nested (architectural) exceptions during those windows, and by not
> applying fixups for SDEI events (SW NMIs that can be taken during those
> windows).
>
> If there's another case to consider, it'd be handy to know.
I'm not aware of more cases.
next prev parent reply other threads:[~2026-09-18 10:59 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 8:48 [PATCH v2 00/12] s390: More this_cpu_*() changes Heiko Carstens
2026-09-18 8:48 ` [PATCH v2 01/12] s390/percpu: Fix comment typo Heiko Carstens
2026-09-18 8:51 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 02/12] s390/percpu: Add sanity check to GEN_MVIY macro Heiko Carstens
2026-09-18 8:54 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 03/12] s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS Heiko Carstens
2026-09-18 8:55 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 04/12] s390/percpu: Let MVIY_PERCPU() calculate alternative displacement Heiko Carstens
2026-09-18 8:56 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 05/12] s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines Heiko Carstens
2026-09-18 8:55 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 06/12] s390/percpu: Rename inline assembly symbolic names Heiko Carstens
2026-09-18 8:51 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 07/12] s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies Heiko Carstens
2026-09-18 8:54 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 08/12] s390/percpu: Use percpu code section for this_cpu_cmpxchg128() Heiko Carstens
2026-09-18 8:56 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 09/12] s390/percpu: Use percpu code section for this_cpu_xchg() Heiko Carstens
2026-09-18 8:56 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 10/12] s390/percpu: Use percpu code section for this_cpu_cmpxchg() Heiko Carstens
2026-09-18 8:55 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 11/12] s390: Add CC_HAS_ASM_M_FORMAT_FLAG config option Heiko Carstens
2026-09-18 8:53 ` sashiko-bot
2026-09-18 8:48 ` [PATCH v2 12/12] s390/percpu: Rework to simplify percpu_entry() and percpu_exit() Heiko Carstens
2026-09-18 9:01 ` sashiko-bot
2026-09-18 9:53 ` Heiko Carstens
2026-09-18 10:40 ` Mark Rutland
2026-09-18 11:02 ` Heiko Carstens
2026-09-18 10:31 ` [PATCH v2 00/12] s390: More this_cpu_*() changes Mark Rutland
2026-09-18 10:59 ` Heiko Carstens [this message]
2026-09-18 11:24 ` 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=20260918105922.20386E38-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=jchrist@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=meted@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=svens@linux.ibm.com \
/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.