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); 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. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
