Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc

[Michael Ellerman <michael@ellerman.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

On Fri, 2009-07-17 at 09:26 +0100, Catalin Marinas wrote:
> On Fri, 2009-07-17 at 10:29 +1000, Michael Ellerman wrote:
> > On Thu, 2009-07-16 at 18:52 +0100, Catalin Marinas wrote:
> > > On Thu, 2009-07-16 at 17:43 +1000, Michael Ellerman wrote:
> > > > On Thu, 2009-07-16 at 11:25 +1000, Michael Ellerman wrote:
> > > > > Very lightly tested, doesn't crash the kernel.
> > > > > 
> > > > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > > > > ---
> > > > > 
> > > > > It doesn't look like we actually need to add any support in the
> > > > > arch code - or is there something I'm missing?
> > > > 
> > > > Hmm, I think we want to add annotations in lib/lmb.c don't we? That's
> > > > our low-level pre-bootmem allocator.
> > > 
> > > Yes, I think so (I'm not using this on ARM or x86 so I can't really test
> > > it). Without these hooks, there kmemleak reports aren't that useful
> > > (probably too many).
> > 
> > The wrinkle is that lmb never frees, so by definition it can't leak :)
> 
> You can pass min_count = 0 to kmemleak_alloc() so that it would never
> report such blocks as leaks (see the alloc_bootmem hooks).

OK. I couldn't see any description of what min_count meant anywhere,
I'll try that though.

> > But we could have memory allocated with lmb that has pointers to other
> > objects allocated later, and we want kmemleak to scan the lmb allocated
> > blocks to find those references.
> > 
> > So the question is do we need to annotate lmb so that will happen, or
> > does kmemleak scan all kernel memory, regardless of where it's
> > allocated?
> 
> Apart from the data and bss sections, it only scans the memory which was
> explicitly allocated. So, you need these hooks in the lmb code.

OK, cool, I'll do a patch to add them.

> The mainline kernel scans for the task stacks by going through the full
> tasks list. However, traversing this list requires a lock which
> increases the latency quite a lot. For the next merging window, I added
> hooks to the alloc_thread_info/free_thread_info functions. If the ppc
> code has __HAVE_ARCH_THREAD_INFO_ALLOCATOR defined, you may need to add
> some hooks in there as well (but note that kmallloc/kmem_cache_alloc are
> tracked by kmemleak already, so you only need the hooks if the
> thread_info allocator uses __get_free_pages).

We do have our own allocator, but it just uses a kmem_cache, so that
should be fine.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]