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 <mich...@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). > 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. 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). -- Catalin _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
