On Tue, Feb 11, 2014 at 12:43:35PM -0600, Christoph Lameter wrote:

On Tue, 11 Feb 2014, Pekka Enberg wrote:

quoted

So again, there's nothing in (A) that the memory allocator is
concerned about.  kmalloc() makes no guarantees whatsoever about the
visibility of "r1" across CPUs.  If you're saying that there's an
implicit barrier between kmalloc() and kfree(), that's an unintended
side-effect, not a design decision AFAICT.

I am not sure that this side effect necessarily happens. The SLUB fastpath
does not disable interrupts and only uses a cmpxchg without lock
semantics.

That tells me what I need to know.  Users should definitely not try a
"drive-by kfree()" of something that was concurrently allocated.  ;-)

							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>