Thread (35 messages) flat view 35 messages, 6 authors, 2026-08-04

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

From: Mark Rutland <mark.rutland@arm.com>
Date: 2026-07-28 16:04:13
Also in: lkml

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help