On Mon, Feb 10, 2014 at 01:07:58PM -0600, Christoph Lameter wrote:

On Sat, 8 Feb 2014, Pekka Enberg wrote:

quoted

So to be completely honest, I don't understand what is the race in (A) that
concerns the *memory allocator*.  I also don't what the memory allocator can
do in (B) and (C) which look like double-free and use-after-free,
respectively, to me. :-)

Well it seems to be some academic mind game to me.

Does an invocation of the allocator have barrier semantics or not?

In case (A), I don't see why the allocator should have barrier semantics
from kmalloc() to a matching kfree().  I would argue that any needed
barrier semantics must be provided by the caller.

In contrast, from kfree() to a kmalloc() returning some of the kfree()ed
memory, I believe the kfree()/kmalloc() implementation must do any needed
synchronization and ordering.  But that is a different set of examples,
for example, this one:

	CPU 0			CPU 1
	p->a = 42;		q = kmalloc(...); /* returning p */
	kfree(p);		q->a = 5;
				BUG_ON(q->a != 5);

Unlike the situation with (A), (B), and (C), in this case I believe
that it is kfree()'s and kmalloc()'s responsibility to ensure that
the BUG_ON() never triggers.

Make sense?

							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>