Subject: Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()

From: Ankur Arora <[email-masked]>
Date: Mon, 16 Mar 2026 23:53:22 -0700

David Laight <[email-masked]> writes:

> On Mon, 16 Mar 2026 15:08:07 -0700
> Ankur Arora <[email-masked]> wrote:
>
> ...
>> However, as David Laight pointed out in this thread
>> (https://lore.kernel.org/lkml/20260214113122.70627a8b@pumpkin/)
>> that this would be fine so long as the polling is on memory, but would
>> need some work to handle MMIO.
>
> I'm not sure the current code works with MMIO on arm64.
>
> I was looking at the osq_lock() code, it uses smp_cond_load() with 'expr'
> being 'VAL || need_resched()' expecting to get woken by the IPI associated
> with the preemption being requested.

Yeah, osq_lock() has:

  if (smp_cond_load_relaxed(&node->locked, VAL || need_resched() ||
                            vcpu_is_preempted(node_cpu(node->prev))))

This works on x86 even with a non-stub vcpu_is_preempted() because we
poll on the node->locked while evaluating the conditional.

Won't work on arm64 since there we are just waiting on node->locked.

(And so we depend on the IPI there.)

> But the arm64 code relies on 'wfe' being woken when the memory write
> 'breaks' the 'ldx' for the monitored location.

Agreed.

> That will only work for cached addresses.

Yeah I was forgetting that. LDXR won't really work with non cacheable
memory. So a generic MMIO version might not be possible at all.

> For osq_lock(), while an IPI will wake it up, there is also a small timing
> window where the IPI can happen before the ldx and so not actually wake up it.
> This is true whenever 'expr' is non-trivial.

Yeah because we are checking the state of more than one address in the
conditional but the waiting monitor only does one memory location at a
time. If only CPUs had vectored waiting mechanisms...

I think the smp_cond_load_*() in poll_idle() and in rqspinlock monitor
a single address (and in the conditional) so those two should be okay.

> On arm64 I think you could use explicit sev and wfe - but that will wake all
> 'sleeping' cpu; and you may not want the 'thundering herd'.

Wouldn't we still have the same narrow window where the CPU disregards the IPI?

--
ankur