linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Christoph Lameter <cl@linux.com>
Cc: Shuah Khan <shuah.khan@hp.com>, Pekka Enberg <penberg@kernel.org>,
	glommer@parallels.com, js1304@gmail.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, shuahkhan@gmail.com
Subject: Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create()
Date: Mon, 16 Jul 2012 12:58:08 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1207161253240.29012@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207160915470.28952@router.home>

On Mon, 16 Jul 2012, Christoph Lameter wrote:

> > > struct kmem_cache *kmem_cache_create(const char *name, size_t size,
> > > size_t align,
> > >                 unsigned long flags, void (*ctor)(void *))
> > > {
> > >         struct kmem_cache *s = NULL;
> > >
> > > #ifdef CONFIG_DEBUG_VM
> > >         if (!name || in_interrupt() || size < sizeof(void *) ||
> > >                 size > KMALLOC_MAX_SIZE) {
> > >                 printk(KERN_ERR "kmem_cache_create(%s) integrity check"
> > >                         " failed\n", name);
> > >                 goto out;
> > >         }
> > > #endif
> > >
> >
> > Agreed, this shouldn't depend on CONFIG_DEBUG_VM.
> 
> These checks are useless for regular kernel operations. They are
> only useful when developing code and should only be enabled during
> development. There is no point in testing the size and the name which are
> typically constant when a slab is created with a stable kernel.
> 

Sounds like a response from someone who is very familiar with slab 
allocators.  The reality, though, is that very few people are going to be 
doing development with CONFIG_DEBUG_VM enabled unless they notice problems 
beforehand.

Are you seriously trying to optimize kmem_cache_create()?  These checks 
certainly aren't going to hurt your perfromance and it seems appropriate 
to do some sanity checking before blowing up in unexpected ways.  It's 
also the way it's been done for years before extracting common allocator 
functions to their own file.

--
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>

  parent reply	other threads:[~2012-07-16 19:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13 23:12 Shuah Khan
2012-07-14  9:18 ` David Rientjes
2012-07-14 12:01   ` Pekka Enberg
2012-07-16  3:04     ` Shuah Khan
2012-07-16  9:58       ` David Rientjes
2012-07-16 14:17         ` Christoph Lameter
2012-07-16 15:56           ` Shuah Khan
2012-07-16 19:58           ` David Rientjes [this message]
2012-07-16 20:14             ` Christoph Lameter
2012-07-16 23:48               ` David Rientjes
2012-07-17 14:36                 ` Christoph Lameter
2012-07-17 14:46                   ` Pekka Enberg
2012-07-17 15:11                     ` Christoph Lameter
2012-07-23  7:04                       ` Glauber Costa
2012-07-25 15:28                         ` Christoph Lameter
2012-07-17 16:52                     ` Shuah Khan
2012-07-30 10:18 ` Pekka Enberg
2012-07-30 19:56   ` David Rientjes
2012-07-30 20:41     ` Pekka Enberg
2012-07-31  2:07       ` David Rientjes
2012-07-31  6:05         ` Pekka Enberg
2012-08-06  3:41   ` Shuah Khan
2012-08-06 15:14     ` [PATCH RESEND] mm: Restructure kmem_cache_create() to move debug cache integrity checks into a new function Shuah Khan
2012-08-06 16:49       ` JoonSoo Kim
2012-08-06 17:03         ` Shuah Khan
2012-08-06 21:13           ` [PATCH v2] " Shuah Khan
2012-08-09 14:06             ` Shuah Khan
2012-08-09 14:13             ` Christoph Lameter (Open Source)
2012-08-09 17:01               ` Shuah Khan
2012-08-09 19:08                 ` Christoph Lameter (Open Source)
2012-08-09 19:33                   ` Shuah Khan
2012-08-12 16:40                     ` [PATCH v3] " Shuah Khan
2012-08-12 17:36                       ` Christoph
2012-08-15 23:53                       ` Andrew Morton
2012-08-16  6:40                         ` Pekka Enberg
2012-08-08 14:14           ` [PATCH RESEND] " Christoph Lameter (Open Source)
2012-08-08 15:13             ` Shuah Khan

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=alpine.DEB.2.00.1207161253240.29012@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=cl@linux.com \
    --cc=glommer@parallels.com \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=shuah.khan@hp.com \
    --cc=shuahkhan@gmail.com \
    /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