Re: [PATCH v4 next 4/9] locking/osq_lock: Delete 'fast path' code from osq_unlock()

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Sep 07, 2026 at 09:41:28AM +0100, David Laight wrote:
> The 'fast path' code in osq_unlock() is pretty much exactly the same as
> the first pass of the loop in osq_wait_next() except that it doesn't
> have the optimisation to avoid the locked RMW when not the tail of
> the list.
> So just call osq_wait_next().
> 
> Move the assignment next->prev_cpu = old_cpu into osq_wait_next()
> as it is always the next line.
> Rename osq_wait_next() to osq_unlink_from_next() since that is what is does.
> 
> Change osq_wait_next() to use atomic_cmpxchg_release() (not _acquire)
> on lock->tail.
> This is what osq_unlock() did and seems right to me.
> 
> Add an smp_wmb() before the 'prev->next = next' assignment when cancelling
> a lock. The previous 'next->prev = prev' assignment lets the 'prev' cpu
> complete an unlocking sequence and do its 'next->prev = prev' assignment
> first - corrupting the list.
> 

This is horrible. From the Changelog alone this should be at least 4
patches.

I've tried to recreate this one patch and ended up with 5.

Please, small steps, no random changes and definitely no
maybe/perhaps like comments when talking about memory barriers.

See here:

  https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=locking/osq