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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
