On Fri, 17 Jun 2016, Davidlohr Bueso wrote:

On Fri, 17 Jun 2016, Waiman Long wrote:

quoted

On 06/16/2016 09:11 PM, Davidlohr Bueso wrote:

quoted

On Wed, 15 Jun 2016, Peter Zijlstra wrote:

quoted

Yeah, see a few patches further in this series, where he guards a
variables with the osq_lock.

So one problem I have with all this is that if we are hardening 
osq_lock/unlock()
because of some future use that is specific to rwsems, then we 
will immediately
be hurting mutexes for no good reason.

I am going to change it to use smp_acquire__after_ctrl_dep() as 
suggested by PeterZ. Is that a good enough compromise? I have also 
changed the xchg in the unlock side to xchg_release which could help 
performance in some archs. The thing is when developers see the name 
osq_lock/osq_unlock, they will naturally assume the proper barrriers 
are provided which is not currently the case.

Oh, from your discussions with Boqun, I was under the impression that ->locked
was now going to be properly ordered in all cases now, which is why
I worry about mutexes.

quoted

Anyway, the change won't affect x86, it is probably ARM or PPC that 
may have an impact.

Yes, that xchg() won't affect x86, but adding an smp_store_release(node->locked, 1)
or such will obviously.

nm this last part, you're right, x86 smp_store_release is a nop.