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 <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).
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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
