Re: [PATCH 2/4] kmemleak: Handle percpu memory allocation

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

On Thu, Sep 29, 2011 at 12:56:13PM +0100, Eric Dumazet wrote:
> Le jeudi 29 septembre 2011 à 12:02 +0100, Catalin Marinas a écrit :
> > This patch adds kmemleak callbacks from the percpu allocator, reducing a
> > number of false positives caused by kmemleak not scanning such memory
> > blocks. The percpu chunks are never reported as leaks because of current
> > kmemleak limitations with the __percpu pointer not pointing directly to
> > the actual chunks.
> > 
> > Reported-by: Huajun Li <huajun.li.lee@gmail.com>
> > Cc: Tejun Heo <tj@kernel.org>,
> > Cc: Christoph Lameter <cl@linux-foundation.org>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> 
> I wonder if you tried it on a 16 or 64 cpus machine ?

I only tried on a 4-CPU system and the early log allocations went form
under 400 to nearly 800.

> I guess we should increase CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE default
> 
> Or you could add new kmemleak_percpu_alloc() / kmemleak_percpu_free()
> primitives to not waste entries in early_log[]

If we don't track them in early_log[] before kmemleak is initialised,
they aren't tracked at all so we end up pretty much in the same
situations.

A better approach would be to tell kmemleak about the __percpu pointer
via some additional API (or some other way to detect that it's a
__percpu pointer) and kmemleak would do the for_each_possible_cpu()
conversion when scanning.

The question - can we guarantee that the __percpu pointer returned by
alloc_percpu() does not overlap with some memory block allocated
elsewhere? At least for the first chunk it seems to overlap with the
percpu data section, which is fine as that's not added in kmemleak as an
allocated block.

Allowing overlapping blocks in kmemleak may be a solution but it's not
implemented yet.

-- 
Catalin