All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vernon Mauery <vernux@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: James Morris <jmorris@namei.org>,
	dwalker@mvista.com, linux-kernel@vger.kernel.org
Subject: Re: kfree(NULL)
Date: Fri, 21 Apr 2006 06:56:39 -0700	[thread overview]
Message-ID: <200604210656.40158.vernux@us.ibm.com> (raw)
In-Reply-To: <20060421015412.49a554fa.akpm@osdl.org>

On Friday 21 April 2006 01:54, you wrote:
> James Morris <jmorris@namei.org> wrote:
> > On Fri, 21 Apr 2006, Daniel Walker wrote:
> > > 	I included a patch , not like it's needed . Recently I've been
> > > evaluating likely/unlikely branch prediction .. One thing that I found
> > > is that the kfree function is often called with a NULL "objp" . In fact
> > > it's so frequent that the "unlikely" branch predictor should be
> > > inverted! Or at least on my configuration.
> >
> > It would be helpful to collect some stats on this so we can look at the
> > ratio.
>
> Yes, kfree(NULL) is supposed to be uncommon.  If someone's doing it a lot
> then we should fix up the callers.

Part of the reason it gets done a lot is because some developers on this list 
have told others NOT to check for NULL before calling kfree because kfree 
does that internally.  I was told that.  I can't remember who told me though.

Maybe kfree should really be a wrapper around __kfree which does the real 
work.  Then kfree could be a inlined function or a #define that does the NULL 
pointer check.  Something like the patch below.  This has the advantage of 
both worlds.  If you know your pointer is NULL, call __kfree.  If you are not 
sure and would check anyway, the inline version of kfree checks for you and 
then calls __kfree.

Signed-off-by: Vernon Mauery <vernux@us.ibm.com>

--- a/include/linux/slab.h  2006-03-19 21:53:29.000000000 -0800
+++ b/include/linux/slab.h  2006-04-21 07:47:32.000000000 -0700
@@ -123,7 +123,14 @@ static inline void *kcalloc(size_t n, si
    return kzalloc(n * size, flags);
 }

-extern void kfree(const void *);
+extern void __kfree(const void *);
+static inline void kfree(const void *obj)
+{
+   if (!obj)
+       return;
+   __kfree(obj);
+}
+
 extern unsigned int ksize(const void *);

 #ifdef CONFIG_NUMA
--- a/mm/slab.c 2006-04-21 07:49:42.000000000 -0700
+++ b/mm/slab.c 2006-04-21 07:49:56.000000000 -0700
@@ -3275,13 +3275,11 @@ EXPORT_SYMBOL(kmem_cache_free);
  * Don't free memory not originally allocated by kmalloc()
  * or you will run into trouble.
  */
-void kfree(const void *objp)
+void __kfree(const void *objp)
 {
    struct kmem_cache *c;
    unsigned long flags;
 
-   if (unlikely(!objp))
-       return;
    local_irq_save(flags);
    kfree_debugcheck(objp);
    c = virt_to_cache(objp);
@@ -3289,7 +3287,7 @@ void kfree(const void *objp)
    __cache_free(c, (void *)objp);
    local_irq_restore(flags);
 }
-EXPORT_SYMBOL(kfree);
+EXPORT_SYMBOL(__kfree);
 
 #ifdef CONFIG_SMP
 /**


  reply	other threads:[~2006-04-21 13:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-21  7:03 kfree(NULL) Daniel Walker
2006-04-21  7:22 ` kfree(NULL) James Morris
2006-04-21  8:54   ` kfree(NULL) Andrew Morton
2006-04-21 13:56     ` Vernon Mauery [this message]
2006-04-21 14:07       ` kfree(NULL) Dmitry Fedorov
2006-04-21 15:07         ` kfree(NULL) Jan Engelhardt
2006-04-21 19:22           ` kfree(NULL) Adrian Bunk
2006-04-21 20:30             ` kfree(NULL) Vernon Mauery
2006-04-21 20:54               ` kfree(NULL) Steven Rostedt
2006-04-21 21:38               ` kfree(NULL) Adrian Bunk
2006-04-22 11:56               ` kfree(NULL) Jörn Engel
2006-04-21 23:55     ` kfree(NULL) Paul Mackerras
2006-04-22  7:43       ` kfree(NULL) Pekka Enberg
2006-04-22  8:48         ` kfree(NULL) Paul Mackerras
2006-04-22 15:02           ` kfree(NULL) Pekka Enberg
2006-04-22 18:57           ` kfree(NULL) Hua Zhong
2006-04-22 19:05             ` kfree(NULL) Nick Piggin
2006-04-22 19:22               ` kfree(NULL) Hua Zhong
2006-04-22 19:25                 ` kfree(NULL) Nick Piggin
2006-04-22 20:18                   ` kfree(NULL) Jan Engelhardt
2006-04-23 16:50               ` kfree(NULL) Steven Rostedt
2006-04-22 11:34       ` kfree(NULL) Jesper Juhl
2006-04-21 14:06   ` kfree(NULL) Daniel Walker
     [not found] <63XWg-1IL-5@gated-at.bofh.it>
     [not found] ` <63YfP-26I-11@gated-at.bofh.it>
     [not found]   ` <63ZEY-45n-27@gated-at.bofh.it>
2006-04-21 15:25     ` kfree(NULL) Tilman Schmidt
2006-04-21 16:03       ` kfree(NULL) Daniel Walker
2006-04-21 17:48         ` kfree(NULL) Jörn Engel
2006-04-21 18:00         ` kfree(NULL) Steven Rostedt
2006-04-21 18:42           ` kfree(NULL) Daniel Walker
2006-04-21 18:56             ` kfree(NULL) Steven Rostedt
2006-04-21 19:26           ` kfree(NULL) Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-04-21 21:02 kfree(NULL) Hua Zhong
2006-04-21 21:11 ` kfree(NULL) Daniel Walker
2006-04-21 21:36   ` kfree(NULL) Michael Buesch
2006-04-21 21:42 ` kfree(NULL) Andrew Morton
2006-04-21 21:48   ` kfree(NULL) Andrew Morton
2006-04-21 22:53   ` kfree(NULL) Hua Zhong
2006-04-21 22:58     ` kfree(NULL) Daniel Walker
2006-04-21 23:03       ` kfree(NULL) Hua Zhong
2006-04-21 23:25     ` kfree(NULL) Andrew Morton
2006-04-21 23:27     ` kfree(NULL) Andrew Morton
2006-04-22 11:18   ` kfree(NULL) Jan Engelhardt
2006-04-22 12:05 kfree(NULL) linux

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=200604210656.40158.vernux@us.ibm.com \
    --to=vernux@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dwalker@mvista.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.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.