On Wed, Sep 09, 2015 at 07:21:34PM -0500, Christoph Lameter wrote: > 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. That barrier() is implicit in the fact that kfree() is an external function? Or are my eyes failing me? But yes, a barrier() seems to me to suffice in this situation. Thanx, Paul -- 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>