On Thu, Jan 28, 2016 at 11:45:40AM -0500, Waiman Long wrote:
> Using xchg_release() looks OK to me. As this feature is enabled on x86 only
> for this patch, we can make the change and whoever enabling it for other
> architectures that have a real release function will have to test it.
Ah, I was more thinking about:
/*
* We rely on the memory barrier implied by xchg() below to
* ensure the node initialization is complete before its
* published.
*/
And then use xchg() like you already do.
> >READ/WRITE_ONCE() provide _no_ order what so ever. And the issue here is
> >that we must not do any other stores to nptr after the state_done.
> >
>
> I thought if those macros are accessing the same cacheline, the compiler
> won't change the ordering and the hardware will take care of the proper
> ordering. Anyway, I do intended to change to use smp_store_release() for
> safety.
The macros use a volatile cast, and that ensures the compiler must emit
the store and must emit it as a single store. I'm not 100% sure on the
rules of the compiler reordering volatile accesses, they are not a
compiler barrier.
