From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Pekka J Enberg <penberg@cs.helsinki.fi>,
mpm@selenic.com, linux-mm@kvack.org,
David Miller <davem@davemloft.net>
Subject: Re: Subject: Slab allocators: Remove kmem_cache_name() to fix invalid frees
Date: Wed, 28 May 2008 17:32:05 -0300 [thread overview]
Message-ID: <20080528203205.GL30251@ghostprotocols.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0805281032290.22637@schroedinger.engr.sgi.com>
Em Wed, May 28, 2008 at 10:40:39AM -0700, Christoph Lameter escreveu:
> kmem_cache_name() is used only by the networking subsystem in order to retrieve
> a char * pointer that was passed to kmem_cache_create(). The name of the
> slab was created dynamically by the network subsystem and therefore there
> is a need to free the name when the slab is no longer in use.
>
> This use creates a dependency on the internal workings of the slab
> allocator. It assumes that the slab allocator stores a pointer to the
> string passed in at kmem_cache_create and that the pointer can be
> retrieved later until the slab is destroyed.
>
> SLUB does not follow that expectation for merged slabs. In that case the
> slab name passed to kmem_cache_create() may only be used to create a
> symlink in /sys/kernel/slab. The "name" of the slab that will be returned
> on kmem_cache_name() is the name of the first kmem_cache_create() that
> caused a slab of a certain size to be created.
>
> This can lead to double frees or the freeing of a string constant when
> a slab is destroyed by the network subsystem by the following action in
> ccid_kmem_cache_destroy() (DCCP protocol) and in proto_unregister().
>
> 1. Retrieving the slab name via kmem_cache_name()
> 2. Destroying the slab cache by calling kmem_cache_destroy().
> 3. Freeing the slab name via kfree().
>
> It seems that it is rare to trigger invalid kfrees because the slabs
> with the dynamic names are rarely created (at least on my systems) and
> then destroyed. In many cases it seems that the first name is the actual
> name of slab because of the uniqueness of the slab characteristics. I only
> found these while testing with cpu_alloc patches that influenced the
> sizes of these structures. But I am sure this can also be triggered under
> other conditions.
>
> Fix:
>
> Create special fields in the networking structs to store a pointer to
> names of slab generated. The pointer is then used to free the name of
> the slab after the slab was destroyed.
>
> Drop the support for kmem_cache_name from all slab allocators.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
I'm ok with this, thanks,
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
--
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>
prev parent reply other threads:[~2008-05-28 20:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-28 17:40 Subject: Slab allocators: Remove kmem_cache_name() to fix invalid frees Christoph Lameter
2008-05-28 17:51 ` Matt Mackall
2008-05-28 17:58 ` Christoph Lameter
2008-05-28 18:23 ` Christoph Lameter
2008-05-28 19:48 ` Pekka Enberg
2008-05-28 20:32 ` Arnaldo Carvalho de Melo [this message]
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=20080528203205.GL30251@ghostprotocols.net \
--to=acme@redhat.com \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
/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.