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

[Peter Zijlstra]

On Tue, Jul 28, 2026 at 05:03:57PM +0100, Mark Rutland wrote:
> 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 :/

Fair enough.