[email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
