On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > I don't see WRITE_ONCE inserting any barriers, release or > > > write. > > > > Correct, never claimed there was. > > > > Just saying that: > > > > obj = READ_ONCE(*foo); > > val = READ_ONCE(obj->val); > > > > Never needs a barrier (except on Alpha and we want to make that go > > away). Simply because a CPU needs to complete the load of @obj before it > > can compute the address &obj->val. Thus the second load _must_ come > > after the first load and we get LOAD-LOAD ordering. > > > > Alpha messing that up is a royal pain, and Alpha not being an > > active/living architecture is just not worth the pain of keeping this in > > the generic model. > > > > Right. What I am saying is that for writes you need > > WRITE_ONCE(obj->val, 1); > smp_wmb(); > WRITE_ONCE(*foo, obj); I believe Peter was instead suggesting: WRITE_ONCE(obj->val, 1); smp_store_release(foo, obj); > and this barrier is no longer paired with anything until > you realize there's a dependency barrier within READ_ONCE. > > Barrier pairing was a useful tool to check code validity, > maybe there are other, better tools now. There are quite a few people who say that smp_store_release() is easier for the tools to analyze than is smp_wmb(). My experience with smp_read_barrier_depends() and rcu_dereference() leads me to believe that they are correct. Thanx, Paul _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
