> On Wed, May 18, 2016 at 02:16:39PM -0700, Steve Wise wrote: > > The default generic barriers are not correct for ARM64. This results in > > data corruption. The correct macros are lifted from the linux kernel. > > > > Signed-off-by: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx> > > > > I wonder why the linux kernel doesn't export these? Also, if the hw > > platform is unknown, I don't think libibverbs should pick a default > > implementation that might cause data corruption. Rather, I think it > > should just fail a compile on that platform. > > These days, in user space this sort of stuff should be done following > the C11 atomic memory ordering model and not by trying to shoe-horn in > the kernel model. Then the compiler takes care of things properly. > > This is using calls like atomic_store, atomic_load and > atomic_thread_fence to create the same sort of barriers. > > You could probably implement the Xmbs() with variations on > atomic_thread_fence ?? Looking at the documentation, it is not clear to me which parameter value passed to atomic_thread_fence() maps to each of the mb services. Is it correct to think that if I get it right, the resulting assembly should be what we currently have for the mb services? Or perhaps someone else can provide guidance? Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
