From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
torvalds@linux-foundation.org, fengguang.wu@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kmemleak: Only use GFP_KERNEL|GFP_ATOMIC for the internal allocations
Date: Wed, 17 Jun 2009 16:01:22 +0300 [thread overview]
Message-ID: <84144f020906170601l254d3b29udc688d02426ea247@mail.gmail.com> (raw)
In-Reply-To: <1245243130.11889.27.camel@pc1117.cambridge.arm.com>
Hi Catalin,
On Wed, Jun 17, 2009 at 3:52 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
> Kmemleak allocates memory for pointer tracking and it tries to avoid
> using GFP_ATOMIC if the caller doesn't require it. However other gfp
> flags may be passed by the caller which aren't required by kmemleak.
> This patch filters the gfp flags so that only GFP_KERNEL | GFP_ATOMIC
> are used.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Is this really safe? What if we're in a middle of a filesystem
operation that uses GFP_NOFAIL and all of a sudden kmemleak allocation
fails and causes a panic?
Pekka
> ---
> mm/kmemleak.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 58ec86c..25e2034 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -109,6 +109,9 @@
>
> #define BYTES_PER_POINTER sizeof(void *)
>
> +/* GFP bitmask for kmemleak internal allocations */
> +#define GFP_KMEMLEAK_MASK (GFP_KERNEL | GFP_ATOMIC)
> +
> /* scanning area inside a memory block */
> struct kmemleak_scan_area {
> struct hlist_node node;
> @@ -462,7 +465,7 @@ static void create_object(unsigned long ptr, size_t size, int min_count,
> struct prio_tree_node *node;
> struct stack_trace trace;
>
> - object = kmem_cache_alloc(object_cache, gfp & ~GFP_SLAB_BUG_MASK);
> + object = kmem_cache_alloc(object_cache, gfp & GFP_KMEMLEAK_MASK);
> if (!object) {
> kmemleak_panic("kmemleak: Cannot allocate a kmemleak_object "
> "structure\n");
> @@ -636,7 +639,7 @@ static void add_scan_area(unsigned long ptr, unsigned long offset,
> return;
> }
>
> - area = kmem_cache_alloc(scan_area_cache, gfp & ~GFP_SLAB_BUG_MASK);
> + area = kmem_cache_alloc(scan_area_cache, gfp & GFP_KMEMLEAK_MASK);
> if (!area) {
> kmemleak_warn("kmemleak: Cannot allocate a scan area\n");
> goto out;
>
>
> --
> 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:[~2009-06-17 13:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200906162232.n5GMWRZe026963@imap1.linux-foundation.org>
[not found] ` <20090616223649.719ea378.akpm@linux-foundation.org>
2009-06-17 11:18 ` [PATCH] pagemap: add page-types tool, fix build Ingo Molnar
2009-06-17 11:31 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Ingo Molnar
2009-06-17 11:35 ` Ingo Molnar
2009-06-17 12:19 ` [PATCH] profile: Suppress warning about large allocations when profile=1 is specified Mel Gorman
2009-06-20 10:09 ` Heinz Diehl
2009-06-20 19:50 ` Mel Gorman
2009-06-20 21:48 ` Heinz Diehl
2009-06-22 11:31 ` Mel Gorman
2009-06-22 13:50 ` Heinz Diehl
2009-06-22 19:58 ` Mel Gorman
2009-06-22 17:00 ` Arnaldo Carvalho de Melo
2009-06-17 11:41 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Mel Gorman
2009-06-17 12:11 ` Catalin Marinas
2009-06-17 12:28 ` Mel Gorman
2009-06-17 12:36 ` Catalin Marinas
2009-06-17 12:40 ` Mel Gorman
2009-06-17 12:52 ` [PATCH] kmemleak: Only use GFP_KERNEL|GFP_ATOMIC for the internal allocations Catalin Marinas
2009-06-17 13:01 ` Pekka Enberg [this message]
2009-06-17 13:23 ` Catalin Marinas
2009-06-17 13:30 ` Pekka Enberg
2009-06-17 15:36 ` [PATCH] kmemleak: Rename kmemleak_panic to kmemleak_stop Catalin Marinas
2009-06-17 15:37 ` Pekka Enberg
2009-06-17 17:14 ` Daniel Walker
2009-06-17 17:27 ` Catalin Marinas
2009-06-17 16:39 ` WARNING: at mm/page_alloc.c:1159 get_page_from_freelist+0x325/0x655() Linus Torvalds
2009-06-17 16:52 ` Ingo Molnar
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=84144f020906170601l254d3b29udc688d02426ea247@mail.gmail.com \
--to=penberg@cs.helsinki.fi \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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
Powered by JetHome