Possible kmemleak issue, but I'm confused

[Tim Bird <tim.bird@am.sony.com>]

Hi Catalin,

I wasn't sure what list to post this to.  Is there a list where
kmemleak is predominately discussed, outside of LKML?

I have a "fix" for kmemleak that we are using in Sony's
Linux kernel (circa 2.6.29), that I wanted to discuss with
you and possibly push upstream.  However, I'm confused about
the status of kmemleak in current mainline.

In our patch set against 2.6.29, there are some kmemleak
instrumentation hooks in kernel/module.c, in the routines
percpu_modalloc and  percpu_modfree.  I thought that all
of kmemleak got mainlined in 2.6.34, but I don't see these
hooks in Linus' latest tree.

I found the commit that we are modifying, in your tree at:
http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff;h=4f2294b6dc88d99295230d97fef2c9863cec44c3

What is the status of this patch relative to linux-next or Linus'
tree?

Here's the issue we found (I'm parroting this from some
developers in Japan who are actually found the issue, so please
forgive me if I mangle the explanation):

The kmemleak_alloc and kmemleak_free in percpu_modalloc
and percpu_modfree routines are capturing allocations/frees
of percpu data areas when a module is loaded or unloaded,
respectively.  However, on some platforms, the percpu
memory area is instantiated by the bootmem allocator,
and the memory in question is already tracked by kmemleak.

When a module is loaded and unloaded multiple times, it
causes problems for kmemleak.  The bug report I'm looking at
says "kmemleak stops", but I don't know what that means. I
can ask for clarification if needed.

Have you heard of this issue?

Our solution was just to make these specific calls to kmemleak_alloc
and kmemleak_free (in module.c) compile-time configurable.
I suspect that there is a better way to do this -- possibly by
detecting or noting that this situation exists for certain
platforms, and avoiding it without specific user interaction.

Anyway, any help you can provide would be appreciated.

I thought I'd contact you and clarify the situation before
trying to push our existing patch, or reimplement it based on
my current understanding.

Thanks,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================