Date: Mon, 19 Dec 2005 02:20:59 -0800
From: Andrew Morton <akpm@osdl.org>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
Message-Id: <20051219022059.36443421.akpm@osdl.org>
In-Reply-To: <200512181258.jBICwMdj003410@turing-police.cc.vt.edu>
References: <200512181258.jBICwMdj003410@turing-police.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1125
Lines: 32

Valdis.Kletnieks@vt.edu wrote:
>
> So I've got a (probably self-inflicted) memory leak in slab-64 and slab-32.
> Rebuild the kernel with CONFIG_DEBUG_SLAB, reboot, and wait for a bit of
> leak to pile up, and then echo 'slab-32 0 0 0' > /proc/slabinfo
> 
> And ta-DA! the top offender is... (drum roll): <kzalloc+0xe/0x36>
> 
> Blargh.  It's tempting to do something like this in include/linux/slab.h:
> 
> #ifdef CONFIG_SLAB_DEBUG
> static inline void* kzalloc(size_t size, gfp_t flags)
> {
>         void *ret = kmalloc(size, flags);
>         if (ret)
>                 memset(ret, 0, size);
>         return ret;
> }
> #else
> extern void *kzalloc(size_t, gfp_t);
> #end

That would work.

Or we could special-case kzalloc() and kstrdup() in slab.c - use
builtin_return_address(1) if builtin_return_address(0) is within those
functions.  Dunno if that's worth the fuss though.
-
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/