lkml.org 
[lkml]   [2005]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
From
Date
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

or maybe some ad-crock macro implementation, just so the actual calling site of
kmalloc is recorded, rather than losing the caller of kzalloc.

Only problems are that (a) changing CONFIG_DEBUG_SLAB will probably recompile
the world rather than just mm/slab.c, and (b) it's 7AM and I've been chasing this
for 6 hours and not sure how to handle the actual body in mm/util.c (wrap the
kzalloc() with a #ifndev CONFIG_DEBUG_SLAB maybe)?
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-12-18 19:17    [W:0.039 / U:2.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site