On Wed, 9 Sep 2015, Paul E. McKenney wrote: > The CPU is indeed constrained in this way, but the compiler is not. > In particular, the CPU must do exact alias analysis, while the compiler > is permitted to do approximate alias analysis in some cases. However, > in gcc builds of the Linux kernel, I believe that the -fno-strict-aliasing > gcc command-line argument forces exact alias analysis. > > Dmitry, anything that I am missing? > > > The transfer to another processor is guarded by locks and I think that > > those are enough to ensure that the cachelines become visible in a > > controlled fashion. > > For the kfree()-to-kmalloc() path, I do believe that you are correct. > Dmitry's question was leading up to the kfree(). The kmalloc-to-kfree path has similar bounds that ensure correctness. First of all it is the availability of the pointer and the transfer of the contents of the pointer to a remove processor. Strictly speaking the processor would violate the rule that there cannnot be a memory access to the object after kfree is called if the compiler would move a store into kfree(). But then again kfree() contains a barrier() which would block the compiler from moving anything into the free path. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>