From: Christoph Lameter <clameter@sgi.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org
Subject: Re: [RFC 0/4] CONFIG_STABLE to switch off development checks
Date: Fri, 1 Jun 2007 11:38:11 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0706011126030.2284@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <46603371.50808@goop.org>
On Fri, 1 Jun 2007, Jeremy Fitzhardinge wrote:
> Perhaps I missed it, but what's the rationale for complaining about
> 0-sized allocations? They seem like a perfectly reasonable thing to me;
> they turn up at the boundary conditions of many algorithms, and avoiding
> them just cruds up the callsites to make them go through hoops to avoid
> allocation.
Hmmm... We got there because SLUB initially return NULL for kmalloc(0).
Rationale: The user did not request any memory so we wont give him
any.
That (to my surprise) caused some strange behavior of code and so we then
decided to keep SLAB behavior and return the smallest available object
size and put a warning in there. At some later point we plan to switch
to returning NULL for kmalloc(0).
> Why not just do a 1 byte allocation instead, and be done with it? Any
> non-constant-sized allocation will potentially have to deal with this
> case, so it seems to me we could just put the fix in common code (and
> use an inline wrapper to avoid it when dealing with constant non-zero
> sized allocations).
The smallest allocation that SLUB can do is 8 bytes (SLAB 32). We are
giving the user the smallest object that we can allocate. We could just
remove the warning and would have the behavior that you want.
But now allocating code gets memory although none was requested. The
object can be modified without us being able to check.
By returning NULL any use of the returned pointer would BUG.
An allocation of zero bytes usually indicates that the code is not dealing
with a special case. Later code may operate on the allocated object. I
think its clearer and cleaner if code would deal with that special case
explicitly. We have seen a series of code pieces that do uncomfortably
looking operations on structures with no objects.
--
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>
next prev parent reply other threads:[~2007-06-01 18:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-31 0:20 clameter
2007-05-31 0:20 ` [RFC 1/4] CONFIG_STABLE: Define it clameter
2007-05-31 0:35 ` young dave
2007-05-31 0:49 ` Christoph Lameter
2007-06-01 18:08 ` Dave Jones
2007-06-01 18:25 ` Christoph Lameter
2007-05-31 8:54 ` Stefan Richter
2007-05-31 9:03 ` David Miller, Stefan Richter
2007-05-31 9:03 ` Stefan Richter
2007-05-31 21:11 ` Andrew Morton
2007-05-31 21:14 ` Christoph Lameter
2007-05-31 21:30 ` Sam Ravnborg
2007-06-01 18:02 ` Dave Jones
2007-06-01 20:22 ` Sam Ravnborg
2007-06-01 20:30 ` Dave Jones
2007-06-01 20:55 ` Sam Ravnborg
2007-06-01 20:25 ` Sam Ravnborg
2007-07-20 10:41 ` Satyam Sharma
2007-07-20 11:09 ` Chris Snook
2007-07-20 11:27 ` Satyam Sharma
2007-07-20 11:34 ` Chris Snook
2007-07-20 11:40 ` Satyam Sharma
2007-07-20 11:50 ` Chris Snook
2007-07-20 16:48 ` Stefan Richter
2007-07-20 16:28 ` Stefan Richter
2007-07-20 16:36 ` Stefan Richter
2007-07-20 19:09 ` Chuck Ebbert
2007-05-31 0:20 ` [RFC 2/4] CONFIG_STABLE: Switch off kmalloc(0) tests in slab allocators clameter
2007-05-31 19:51 ` Zach Brown
2007-05-31 22:37 ` Andi Kleen
2007-05-31 0:20 ` [RFC 3/4] CONFIG_STABLE: Switch off SLUB banner clameter
2007-05-31 0:20 ` [RFC 4/4] CONFIG_STABLE: SLUB: Prefer object corruption over failure clameter
2007-06-01 14:55 ` [RFC 0/4] CONFIG_STABLE to switch off development checks Jeremy Fitzhardinge
2007-06-01 18:38 ` Christoph Lameter [this message]
2007-06-01 18:58 ` Jeremy Fitzhardinge
2007-06-01 20:59 ` Christoph Lameter
2007-06-01 21:24 ` Jeremy Fitzhardinge
2007-06-02 15:23 ` Dave Kleikamp
2007-06-02 16:28 ` Jeremy Fitzhardinge
2007-06-04 1:03 ` Dave Kleikamp
[not found] <fa.UBCbBXgIW93M6j2F+d+umQ5+v9I@ifi.uio.no>
[not found] ` <fa.iaekQW/Par/E6eIpnL0NjEdCUxc@ifi.uio.no>
[not found] ` <fa.2BlkzuhauAATrsG1MYhPMeWMhPM@ifi.uio.no>
[not found] ` <fa.o9WA1K75HxwNnBEQDyoQMfWVpiQ@ifi.uio.no>
[not found] ` <fa.wiSgrIhkRNkkC7Wh6Bt3BY4z7BM@ifi.uio.no>
2007-06-05 0:38 ` Robert Hancock
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=Pine.LNX.4.64.0706011126030.2284@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox