Linus Torvalds writes: (Summary) wrote:
Hmm.
Hmm.
I thought we had exactly that bug on some architecture with the queued spinlocks, and people decided it was wrong.
spinlocks, and people decided it was wrong.
But it's possible that I mis-remember, and that we decided it was ok after all. Is that relied on somewhere?
I have a distinct memory that we said the spinlock write is seen in order, wrt the writes inside the spinlock, and the reason was something very similar to the above, except that "spin_is_locked()" was about our spin_unlock_wait().
was about our spin_unlock_wait().
Because we had something very much like the above in the exit path, where we would look at some state and do "spin_unlock_wait()" and expect to be guaranteed to be the last user after that.
[...]
order on the lock/unlock operations for the lock.Hmm.
Hmm.
I thought we had exactly that bug on some architecture with the queued spinlocks, and people decided it was wrong.
spinlocks, and people decided it was wrong.
But it's possible that I mis-remember, and that we decided it was ok after all. Is that relied on somewhere?
I have a distinct memory that we said the spinlock write is seen in order, wrt the writes inside the spinlock, and the reason was something very similar to the above, except that "spin_is_locked()" was about our spin_unlock_wait().
was about our spin_unlock_wait().
Because we had something very much like the above in the exit path, where we would look at some state and do "spin_unlock_wait()" and expect to be guaranteed to be the last user after that.
