Re: [PATCH] lockdep: Add a document describing crossrelease feature

[Byungchul Park]

On Wed, Jul 06, 2016 at 09:56:08AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 06, 2016 at 02:33:29PM +0900, Byungchul Park wrote:
> > On Wed, Jul 06, 2016 at 11:17:10AM +0900, Byungchul Park wrote:
> > > 
> > > lock(A)
> > > wait_for(B)
> > > ~~~~~~~~~~~~~~~~~~~~~~~~ <- serialized by atomic operation
> > > 		lock(A)
> > > 		unlock(A)
> > > 		wake(B)
> > > unlock(A)
> > 
> > By the way, I have a question. Is there anyone who could answer it?
> > 
> > I want to serialize between two context's lock operations, for example,
> > 
> > 	context A	context B
> > 	--------------	--------------
> > 	lock A
> > 	lock B		...
> > 	lock C
> > 	atomic_inc_return
> > 	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <- serialization
> > 			atomic_read
> > 			lock D
> > 	...		lock E
> > 			lock F
> > 
> > so that we can see these in the order like A -> B -> C -> D -> E -> F.
> > 
> > atomic_inc_return() is used after lock C in context A, and atomic_read()
> > is used before lock D in context B. And I want to make it serialized when
> > the atomic_read() can see the increased value.
> > 
> > Can I use smp_mb__after_atomic() just after atomic_read() 
> 
> No. atomic_set() and atomic_read() are not RmW operations.
> 
> > or should I use
> > smp_mb()? I think anyway I have to choose one of them for that ordering.
> 
> smp_load_acquire(), if that observes the increment it will ensure D
> comes after etc..
> 
> Also, atomic_read() _could_ be enough, if its part of a control
> dependency, because LOCK very much involves a store, so the load->store
> order provided by the control dependency will already order things.

Indeed. Thank you very much.

I can rely on the control dependency if possible. I will check it.

Thank you,
Byungchul