[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020811201130y2de91d03q7e6557e4086147ad@mail.gmail.com>
Date: Thu, 20 Nov 2008 21:30:08 +0200
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Catalin Marinas" <catalin.marinas@....com>
Cc: linux-kernel@...r.kernel.org, "Matt Mackall" <mpm@...enic.com>,
"Christoph Lameter" <cl@...ux-foundation.org>
Subject: Re: [PATCH 2.6.28-rc5 03/11] kmemleak: Add the memory allocation/freeing hooks
Hi Catalin,
On Thu, Nov 20, 2008 at 1:30 PM, Catalin Marinas
<catalin.marinas@....com> wrote:
> This patch adds the callbacks to memleak_(alloc|free) functions from
> kmalloc/kfree, kmem_cache_(alloc|free), vmalloc/vfree etc.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@....com>
[snip]
> @@ -2610,6 +2611,9 @@ static struct slab *alloc_slabmgmt(struct kmem_cache *cachep, void *objp,
> /* Slab management obj is off-slab. */
> slabp = kmem_cache_alloc_node(cachep->slabp_cache,
> local_flags & ~GFP_THISNODE, nodeid);
> + /* only scan the list member to avoid false negatives */
> + memleak_scan_area(slabp, offsetof(struct slab, list),
> + sizeof(struct list_head));
I find this comment somewhat confusing. Does it mean we _must_ scan
the list members to avoid false negatives (i.e. leaks that happened
but were not reported) or that if we scan the whole of struct slab, we
get false negatives?
> if (!slabp)
> return NULL;
> } else {
Other than that, the SLAB, SLUB, and SLOB hooks look good to me. You
might want to split up the patch a bit and CC Matt for the SLOB and
Christoph for the SLUB hooks and me for all of the three.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists