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

[David Laight]

On Tue, 15 Sep 2026 07:19:05 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Mon, Sep 14, 2026 at 10:30:12PM -0400, Waiman Long wrote:
> > On 9/14/26 7:22 AM, Peter Zijlstra wrote:  
> 
> > > This doesn't make sense. You cannot argue that the code is correct as is
> > > and still add Fixes.  
> > 
> > That is true. I added this paragraph to show that it is not a serious bug,
> > but I still think it is better to fix it or we have to explicitly say that
> > it is not a real lock in term of how it can be used. I have taken it out to
> > avoid confusion.  
> 
> "It is not a real lock" will do. It has always been meant as a optimistic
> spin queue -- very much not a lock.
> 
> 

I'm not so sure, assuming that is probably short sighted and it will
cause grief sometime in the future.

I did start trying to locate the actual race.
If a read barrier fixes it there must be two reads that get swapped,
so it should be possible to find them.
Unfortunately I don't have a system that is likely to reproduce the error.

David