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

[Waiman Long <longman@redhat.com>]

On 9/14/26 6:30 AM, Haakon Bugge wrote:
> [$Subject fixed]
>
>> On 10 Sep 2026, at 16:19, Waiman Long <longman@redhat.com> 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