Re: [PATCH] locking/osq_lock: Ensure proper locking semantics for osq_lock/osq_unlock()

[Waiman Long]

On 9/14/26 6:30 AM, Haakon Bugge wrote:
> [$Subject fixed]
>
> > On 10 Sep 2026, at 16:19, Waiman Long <longman@xxxxxxxxxx> wrote:
> >
> > The osq_lock is special in the sense that lock transfer from one CPU to
> > the next can happen either over the common optimistic_spin_queue.tail
> > value with uncontended lock or over a lock waiter's own percpu
> > optimistic_spin_node.locked flag when the lock is contended.
> >
> > To ensure proper lock synchronization, we need to provide
> > the acquire/release semantics for the osq_lock/osq_unlock()
> > functions in both cases. This is currently the case for the
> > common optimistic_spin_queue.tail value, but not for the percpu
> > optimistic_spin_node.locked flag as the proper barriers are missing in
> > some places. Fix that by adding the needed barriers in those places.
> >
> > Note that the two percpu optimistic_spin_node.locked setting in
> > osq_unlock() are proceeded by a full barrier xchg() call, but the
>
> s/proceeded/preceded/
>
> > contended cachelines are different. This should probably work in most
> > cases except in some exotic architectures where the barrier semantics
> > may be cacheline specific.
>
> As of today, doesn't atomic_xchg() provide full memory barrier?
> From the doc: "RMW operations that have a return value are fully
> ordered". I assume this applies to both the intra- and inter-
> cacheline cases.

Yes, you are right. That is why I decide to keep the WRITE_ONCE() in v2/v3.

Cheers,
Longman