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:
quoted
On Tue, Jul 28, 2026 at 01:38:52PM +0100, Mark Rutland wrote:
quoted
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!
quoted
quoted
| 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.