From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pekka Enberg <penberg@iki.fi>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cl@linux-foundation.org, penberg@kernel.org, mpm@selenic.com
Subject: Re: Memory allocator semantics
Date: Sat, 8 Feb 2014 18:00:04 -0800 [thread overview]
Message-ID: <20140209020004.GY4250@linux.vnet.ibm.com> (raw)
In-Reply-To: <52F60699.8010204@iki.fi>
On Sat, Feb 08, 2014 at 12:27:37PM +0200, Pekka Enberg wrote:
> Hi Paul,
>
> On 01/02/2014 10:33 PM, Paul E. McKenney wrote:
> > From what I can see, the Linux-kernel's SLAB, SLOB, and SLUB memory
> >allocators would deal with the following sort of race:
> >
> >A. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(gp) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(gp); if (r2) kfree(r2);
> >
> >However, my guess is that this should be considered an accident of the
> >current implementation rather than a feature. The reason for this is
> >that I cannot see how you would usefully do (A) above without also allowing
> >(B) and (C) below, both of which look to me to be quite destructive:
> >
> >B. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(shared_x); if (r2) kfree(r2);
> >
> > CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
> >
> > This results in the memory being on two different freelists.
> >
> >C. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(shared_x); r2->a = 1; r2->b = 2;
> >
> > CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
> >
> > CPU 3: r4 = kmalloc(...); r4->s = 3; r4->t = 4;
> >
> > This results in the memory being used by two different CPUs,
> > each of which believe that they have sole access.
> >
> >But I thought I should ask the experts.
> >
> >So, am I correct that kernel hackers are required to avoid "drive-by"
> >kfree()s of kmalloc()ed memory?
>
> 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. :-)
>From what I can see, (A) works by accident, but is kind of useless because
you allocate and free the memory without touching it. (B) and (C) are the
lightest touches I could imagine, and as you say, both are bad. So I
believe that it is reasonable to prohibit (A).
Or is there some use for (A) that I am missing?
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pekka Enberg <penberg@iki.fi>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cl@linux-foundation.org, penberg@kernel.org, mpm@selenic.com
Subject: Re: Memory allocator semantics
Date: Sat, 8 Feb 2014 18:00:04 -0800 [thread overview]
Message-ID: <20140209020004.GY4250@linux.vnet.ibm.com> (raw)
In-Reply-To: <52F60699.8010204@iki.fi>
On Sat, Feb 08, 2014 at 12:27:37PM +0200, Pekka Enberg wrote:
> Hi Paul,
>
> On 01/02/2014 10:33 PM, Paul E. McKenney wrote:
> > From what I can see, the Linux-kernel's SLAB, SLOB, and SLUB memory
> >allocators would deal with the following sort of race:
> >
> >A. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(gp) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(gp); if (r2) kfree(r2);
> >
> >However, my guess is that this should be considered an accident of the
> >current implementation rather than a feature. The reason for this is
> >that I cannot see how you would usefully do (A) above without also allowing
> >(B) and (C) below, both of which look to me to be quite destructive:
> >
> >B. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(shared_x); if (r2) kfree(r2);
> >
> > CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
> >
> > This results in the memory being on two different freelists.
> >
> >C. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
> >
> > CPU 1: r2 = ACCESS_ONCE(shared_x); r2->a = 1; r2->b = 2;
> >
> > CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
> >
> > CPU 3: r4 = kmalloc(...); r4->s = 3; r4->t = 4;
> >
> > This results in the memory being used by two different CPUs,
> > each of which believe that they have sole access.
> >
> >But I thought I should ask the experts.
> >
> >So, am I correct that kernel hackers are required to avoid "drive-by"
> >kfree()s of kmalloc()ed memory?
>
> 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. :-)
>From what I can see, (A) works by accident, but is kind of useless because
you allocate and free the memory without touching it. (B) and (C) are the
lightest touches I could imagine, and as you say, both are bad. So I
believe that it is reasonable to prohibit (A).
Or is there some use for (A) that I am missing?
Thanx, Paul
next prev parent reply other threads:[~2014-02-09 2:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-02 20:33 Memory allocator semantics Paul E. McKenney
2014-01-02 20:33 ` Paul E. McKenney
2014-01-03 3:39 ` Josh Triplett
2014-01-03 3:39 ` Josh Triplett
2014-01-03 5:14 ` Paul E. McKenney
2014-01-03 5:14 ` Paul E. McKenney
2014-01-03 5:47 ` Josh Triplett
2014-01-03 5:47 ` Josh Triplett
2014-01-03 7:57 ` Paul E. McKenney
2014-01-03 7:57 ` Paul E. McKenney
2014-01-03 8:42 ` Josh Triplett
2014-01-03 8:42 ` Josh Triplett
2014-02-08 10:27 ` Pekka Enberg
2014-02-08 10:27 ` Pekka Enberg
2014-02-09 2:00 ` Paul E. McKenney [this message]
2014-02-09 2:00 ` Paul E. McKenney
2014-02-11 8:50 ` Pekka Enberg
2014-02-11 8:50 ` Pekka Enberg
2014-02-11 12:09 ` Paul E. McKenney
2014-02-11 12:09 ` Paul E. McKenney
2014-02-11 18:43 ` Christoph Lameter
2014-02-11 18:43 ` Christoph Lameter
2014-02-14 17:30 ` Paul E. McKenney
2014-02-14 17:30 ` Paul E. McKenney
2014-02-10 19:07 ` Christoph Lameter
2014-02-10 19:07 ` Christoph Lameter
2014-02-11 12:14 ` Paul E. McKenney
2014-02-11 12:14 ` Paul E. McKenney
2014-02-11 13:20 ` Pekka Enberg
2014-02-11 13:20 ` Pekka Enberg
2014-02-11 15:01 ` Paul E. McKenney
2014-02-11 15:01 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140209020004.GY4250@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@iki.fi \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.