Re: linux-next: manual merge of the kmemleak tree

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

On Tue, 2009-04-21 at 12:14 +0100, Catalin Marinas wrote:
> On Thu, 2009-01-15 at 19:49 +0200, Eduard - Gabriel Munteanu wrote:
> > On Thu, Jan 15, 2009 at 12:04:57PM +0000, Catalin Marinas wrote:
> > > The only issue is that kmemleak would need to register the callbacks
> > > before the slab allocator is initialised (otherwise it may miss some
> > > allocations). So it would need a 3-stage initialisation - pre-slab,
> > > post-slab and late_initcall.
> > 
> > Sure, that is not a problem, as kmemtrace needn't be compiled in for
> > the tracepoints to work. As long as they're defined in some header and
> > included, you can register multiple probes from all over the kernel.
> > This also means you won't have to interact with kmemtrace code.
> 
> I noticed that the memory allocation tracepoints were merged into
> mainline. I'll modify kmemleak to use them and probably add another for
> vmalloc.

After a quick look, it turns out not to be so simple. Kmemleak needs to
trace all the memory allocations (missing some could cause false
positives) and it currently has a static buffer to store the first
allocations before kmemleak is fully initialised.

Registering a probe requires memory allocations and therefore it needs
to be done after kmem_cache_init(). It means that kmemleak would miss
several allocations before it can register the probes. I don't see any
solution other than inserting kmemleak_*() calls near the tracing hooks.

Any other suggestion? Thanks.

-- 
Catalin