Re: [RFC PATCH 06/13] arm64: percpu: Add infrastructure for preemptible this_cpu_*() ops

[Mark Rutland]

On Tue, Jul 28, 2026 at 04:30:16PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 28, 2026 at 04:19:58PM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 28, 2026 at 01:38:52PM +0100, Mark Rutland wrote:
> > 
> > > With the scheme added in this patch, this can be compiled as:
> > > 
> > > | <outline_this_cpu_add_u64>:
> > > |        mrs     x2, sp_el0
> > > |        mov     x4, #0xc80
> > > |        strh    w4, [x2, #20]
> > > |        mrs     x4, tpidr_el1
> > > |        add     x3, x0, x4
> > 
> > Which it then recomputes, and so is harmless.
> 
> Here!
> 
> > > | 1:     ldxr    x6, [x3]
> > > |        add     x6, x6, x1
> > > |        stxr    w5, x6, [x3]
> > > |        cbnz    w5, 1b
> > 
> > If we get here and interrupts happens, we recompute pointlessly, no harm
> > done.
> > 
> > Anyway, per this sequence there is no point in ever doing the fixup. So
> > perhaps give a better example?
> 
> Nevermind, brain just wasn't working right, when interrupt happens at
> 'Here!' above, it needs the fixup, irrespective of the atomic type.

Yep!

Note that the atomic type doesn't change things. We need the fixup even
if preemption happens *within* the LDXR...STXR loop, since the inline
sequences branches back to the LDXR, *without* recalculating the addr or
offset, and the fixup *does not* alter the PC.

It's a bit awkaward to spell that out in the commit message without
unrolling the loop :/

Mark.