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

[Peter Zijlstra]

On Tue, Sep 15, 2026 at 01:53:05PM -0400, Waiman Long wrote:

> In your comment to David's "locking/osq_lock: Set prev_cpu=0 instead of
> locked=1" patch, you suggested adding smp_acquire__after_ctrl_dep() after
> finding that the lock had been granted which is exactly what the change from
> smp_cond_load_relaxed() to smp_cond_load_acquire() is doing. Right?

It is similar, yes.

But all I did there was restore an ACQUIRE that David lost, silently.
That loop exit condition was smp_load_acquire() and he made it go away.

Now, you're right in that we can probably survive making it
smp_cond_load_acquire(). However:

 - you get to re-run the numbers from 036cc30c6b6a to show it doesn't
   regress

 - you don't put on Fixes, *unless* you put in a solid argument showing
   what is broken how. And so far, nothing actually needs this ordering
   because osq isn't actually a stand-alone lock -- it was never meant
   to be.