lkml.org 
[lkml]   [2014]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory allocator semantics
On Mon, Feb 10, 2014 at 01:07:58PM -0600, Christoph Lameter wrote:
> On Sat, 8 Feb 2014, Pekka Enberg wrote:
>
> > 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



\
 
 \ /
  Last update: 2014-02-11 15:41    [W:0.080 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site