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

v1:
Most of this is only about cleaning up the percpu code after preemptible
this_cpu_*() operations have been implemented. The first ten patches are
all more or less trivial cleanup patches trying to make the code shorter
and more readable.

The only non-trivial patch is the last one, which converts s390's
this_cpu_*() operations to use a similar scheme like Mark Rutland
provided it for arm64 [1]. This allows to simplify the irq entry and exit
path, however at the cost of slightly worse code for this_cpu_*()
operations.

The simplified irq entry and exit code seems to be worth it. Usable
performance numbers are not available yet, however I don't expect big
difference to before.

[1] https://lore.kernel.org/all/20260904161758.376504-1-mark.rutland@arm.com/

Thanks,
Heiko

Heiko Carstens (12):
  s390/percpu: Fix comment typo
  s390/percpu: Add sanity check to GEN_MVIY macro
  s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS
  s390/percpu: Let MVIY_PERCPU() calculate alternative displacement
  s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines
  s390/percpu: Rename inline assembly symbolic names
  s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies
  s390/percpu: Use percpu code section for this_cpu_cmpxchg128()
  s390/percpu: Use percpu code section for this_cpu_xchg()
  s390/percpu: Use percpu code section for this_cpu_cmpxchg()
  s390: Add CC_HAS_ASM_M_FORMAT_FLAG config option
  s390/percpu: Rework to simplify percpu_entry() and percpu_exit()

 arch/s390/Kconfig                    |   6 +
 arch/s390/include/asm/entry-percpu.h |  71 ++---
 arch/s390/include/asm/lowcore.h      |   5 +-
 arch/s390/include/asm/percpu.h       | 381 +++++++++++++++++----------
 arch/s390/include/asm/ptrace.h       |   2 +-
 arch/s390/kernel/irq.c               |  10 +-
 arch/s390/kernel/nmi.c               |   4 +-
 arch/s390/kernel/traps.c             |   4 +-
 8 files changed, 280 insertions(+), 203 deletions(-)

-- 
2.53.0

Hi Heiko,

This looks neat!

On Fri, Sep 18, 2026 at 10:48:30AM +0200, Heiko Carstens 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
  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)?

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.

Mark.

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.

On Fri, Sep 18, 2026 at 12:59:22PM +0200, Heiko Carstens wrote:
> 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.

Whoops; yes!

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

Perfect, thanks for confirming!

Mark.