Re: Store Buffers (was Re: Is it OK to pass non-acquired objects to kfree?)

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>