From: P Lavin <lavin.p@redpinesignals.com>
To: linux-kernel@vger.kernel.org
Subject: Re: no need to check for NULL before calling kfree() -fs/ext2/
Date: Wed, 30 Mar 2005 12:45:01 +0530 [thread overview]
Message-ID: <424A51F5.1050501@redpinesignals.com> (raw)
In-Reply-To: <courier.424A43A5.00002305@courier.cs.helsinki.fi>
Hi,
In my wlan driver module, i allocated some memory using kmalloc in
interrupt context, this one failed but its not returning NULL , so i was
proceeding further everything was going wrong... & finally the kernel
crahed. Can any one of you tell me why this is happening ? i cannot use
GFP_KERNEL because i'm calling this function from interrupt context & it
may block. Any other solution for this ?? I'm concerned abt why kmalloc
is not returning null if its not a success ??
Is it not necessary to check for NULL before calling kfree() ??
Regards,
Lavin
Pekka J Enberg wrote:
> Hi,
> Paul Jackson writes:
>
>> Even such obvious changes as removing redundant checks doesn't
>> seem to ensure a performance improvement. Jesper Juhl posted
>> performance data for such changes in his microbenchmark a couple
>> of days ago.
>
>
> It is not a performance issue, it's an API issue. Please note that
> kfree() is analogous libc free() in terms of NULL checking. People are
> checking NULL twice now because they're confused whether kfree() deals
> it or not.
> Paul Jackson writes:
>
>> Maybe we should be following your good advice:
>> > You don't know that until you profile!
>> instead of continuing to make these code changes.
>
>
> I am all for profiling but it should not stop us from merging the
> patches because we can restore the generated code with the included
> (totally untested) patch.
> Pekka
> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
> ---
> Index: 2.6/include/linux/slab.h
> ===================================================================
> --- 2.6.orig/include/linux/slab.h 2005-03-22 14:31:30.000000000
> +0200
> +++ 2.6/include/linux/slab.h 2005-03-30 09:08:13.000000000 +0300
> @@ -105,8 +105,14 @@
> return __kmalloc(size, flags);
> }
> +static inline void kfree(const void * p)
> +{
> + if (!p)
> + return;
> + __kfree(p);
> +}
> +
> extern void *kcalloc(size_t, size_t, int);
> -extern void kfree(const void *);
> extern unsigned int ksize(const void *);
> extern int FASTCALL(kmem_cache_reap(int));
> Index: 2.6/mm/slab.c
> ===================================================================
> --- 2.6.orig/mm/slab.c 2005-03-22 14:31:31.000000000 +0200
> +++ 2.6/mm/slab.c 2005-03-30 09:08:45.000000000 +0300
> @@ -2567,13 +2567,11 @@
> * 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)
> {
> kmem_cache_t *c;
> unsigned long flags;
> - if (!objp)
> - return;
> local_irq_save(flags);
> kfree_debugcheck(objp);
> c = GET_PAGE_CACHE(virt_to_page(objp));
> @@ -2581,7 +2579,7 @@
> local_irq_restore(flags);
> }
> -EXPORT_SYMBOL(kfree);
> +EXPORT_SYMBOL(__kfree);
> #ifdef CONFIG_SMP
> /**
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2005-03-30 7:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-25 22:08 [PATCH] no need to check for NULL before calling kfree() - fs/ext2/ Jesper Juhl
2005-03-25 22:29 ` linux-os
2005-03-25 22:44 ` Jesper Juhl
2005-03-26 7:50 ` Pekka Enberg
2005-03-26 8:32 ` Arjan van de Ven
2005-03-26 23:21 ` [PATCH] no need to check for NULL before calling kfree() -fs/ext2/ linux-os
2005-03-26 23:34 ` Marcin Dalecki
2005-03-27 2:00 ` Horst von Brand
2005-03-27 3:18 ` Marcin Dalecki
2005-03-27 22:12 ` linux-os
2005-03-26 23:54 ` Jesper Juhl
2005-03-27 0:05 ` Lee Revell
2005-03-27 10:55 ` Jesper Juhl
2005-03-27 14:56 ` Paul Jackson
2005-03-27 15:12 ` Jan Engelhardt
2005-03-27 17:40 ` Dave Jones
2005-03-27 18:17 ` Jan Engelhardt
2005-03-27 19:25 ` Pekka Enberg
2005-03-27 22:56 ` Jesper Juhl
2005-03-28 4:53 ` Paul Jackson
2005-03-30 18:57 ` Jesper Juhl
2005-03-28 1:20 ` Horst von Brand
2005-03-28 4:10 ` Paul Jackson
2005-03-28 12:58 ` Geert Uytterhoeven
2005-03-29 2:52 ` Lee Revell
2005-03-29 6:30 ` Pekka Enberg
2005-03-29 7:06 ` Jan Engelhardt
2005-03-29 7:24 ` Pekka J Enberg
2005-03-30 2:44 ` Paul Jackson
2005-03-30 6:13 ` Pekka J Enberg
2005-03-30 6:16 ` Paul Jackson
2005-03-30 7:15 ` P Lavin [this message]
2005-03-30 14:20 ` Jesper Juhl
2005-03-30 19:10 ` Jesper Juhl
2005-04-09 2:21 ` Jesper Juhl
2005-03-28 4:07 ` [PATCH] " Paul Jackson
2005-03-27 8:45 ` Arjan van de Ven
2005-03-27 12:51 ` Denis Vlasenko
2005-03-27 14:28 ` Arjan van de Ven
2005-03-27 23:13 ` [PATCH] no need to check for NULL before calling kfree()-fs/ext2/ linux-os
-- strict thread matches above, loose matches on Subject: below --
2005-03-31 6:30 no need to check for NULL before calling kfree() -fs/ext2/ P Lavin
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=424A51F5.1050501@redpinesignals.com \
--to=lavin.p@redpinesignals.com \
--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.