Re: [PATCH 2.6.17-rc4 1/6] Base support for kmemleak

[Catalin Marinas <catalin.marinas@gmail.com>]

Andi Kleen wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>>This patch adds the base support for the kernel memory leak detector. It
>>traces the memory allocation/freeing in a way similar to the Boehm's
>>conservative garbage collector, the difference being that the orphan
>>pointers are not freed but only shown in /proc/memleak. Enabling this
>>feature would introduce an overhead to memory allocations.
> 
> Interesting approach. Did you actually find any leaks with this? 

I haven't tested it intensively (that's the first version and I mainly
used a minimal kernel on an embedded system) but it could find
explicitely created leaks. For example, it should be able to detect
leaks similar to those fixed recently by Jesper:

http://lkml.org/lkml/2006/5/13/135
http://lkml.org/lkml/2006/5/13/140
http://lkml.org/lkml/2006/5/13/145

The above bugs were found by Coverity when analysing the code. The main
difference is that kmemleak finds them at run-time and only if they
happened.

> What looks a bit dubious is how objects reuse is handled. You can't
> distingush an reused object from an old leaked pointer.

The reused objects are not reported as leaks as long as the tool finds a
pointer to their address (or alias). The memleak_alloc hook is called in
kmem_cache_alloc after the object was actually allocated by
__cache_alloc. An object cannot be reused as long as it hasn't been
previously freed via kmem_cache_free (and the corresponding hook,
memleak_free, called). Kmemleak only reports allocated objects for which
there is no way to determine their address that can later be used in a
kmem_cache_free call.

Catalin