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)?
Attachment:
pgpHOSOgsQQCH.pgp
Description: PGP signature
- Follow-Ups:
- Re: 2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
- From: Andrew Morton <[email protected]>
- Re: 2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
- From: Pekka Enberg <[email protected]>
- Re: 2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
- Prev by Date: Re: swsusp: documentation fixes
- Next by Date: Re: [RFC] swsusp: brainstorming on a freaked-out approach
- Previous by thread: [PATCH rc5-rt2 1/3] plist: remove old implementation
- Next by thread: Re: 2.6.16-rc5-mm2 - kzalloc() considered harmful for debugging.
- Index(es):