From: Matt Mackall <mpm@selenic.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Paul Mundt <lethal@linux-sh.org>,
Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, dhowells@redhat.com
Subject: Re: [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()
Date: Thu, 22 May 2008 13:31:56 -0500 [thread overview]
Message-ID: <1211481116.18026.360.camel@calx> (raw)
In-Reply-To: <84144f020805220913g344baedaqb0996adecdadae99@mail.gmail.com>
On Thu, 2008-05-22 at 19:13 +0300, Pekka Enberg wrote:
> Hi Matt,
>
> On Thu, May 22, 2008 at 6:01 PM, Matt Mackall <mpm@selenic.com> wrote:
> > As I've said several times, ksize() on kmem_cache_alloced objects
> > -cannot work- on SLOB. Calling ksize() on something returned by
> > kmem_cache_alloc is a categorical error.
>
> Well, it's a historical fact that ksize() worked for both kmalloc()
> and kmem_cache_alloc() (see the kernedoc comment in mm/slab.c).
Indeed. It looks like it was in fact introduced for nommu (back in
2.5.47). But much like kfree(kmem_cache_alloc()) is a bogus thing to do,
ksize(kmem_cache_alloc()) is assuming too much about the relationship
between kmalloc and kmem_cache_alloc.
Nommu's accounting code makes two misguided assumptions a) that we can
determine how/whether something was allocated just from a pointer b)
that the size of that object can be determined dynamically in any case
other than kmalloc. But it really shouldn't need to do either of these.
> However, I think we should just look at getting rid of ksize()
> altogether as it's only (ab)used by the nommu code and few call-sites
> that open-code krealloc().
Right.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2008-05-22 18:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 18:25 [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize() Pekka J Enberg
2008-05-21 23:45 ` Paul Mundt
2008-05-22 4:13 ` Pekka Enberg
2008-05-22 4:17 ` Christoph Lameter
2008-05-22 4:21 ` Pekka Enberg
2008-05-22 4:34 ` Paul Mundt
2008-05-22 4:43 ` Pekka Enberg
2008-05-22 4:55 ` Paul Mundt
2008-05-22 15:01 ` Matt Mackall
2008-05-22 16:13 ` Pekka Enberg
2008-05-22 16:51 ` Christoph Lameter
2008-05-22 18:31 ` Matt Mackall [this message]
2008-05-23 14:23 ` Adrian Bunk
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=1211481116.18026.360.camel@calx \
--to=mpm@selenic.com \
--cc=clameter@sgi.com \
--cc=dhowells@redhat.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--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.