From: Catalin Marinas <catalin.marinas@arm.com>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] kmemleak: Allow kmemleak to be built on powerpc
Date: Fri, 17 Jul 2009 09:26:35 +0100 [thread overview]
Message-ID: <1247819195.32760.7.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <1247790558.16836.4.camel@concordia>
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).
> 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
next prev parent reply other threads:[~2009-07-17 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-16 1:25 [PATCH] kmemleak: Allow kmemleak to be built on powerpc Michael Ellerman
2009-07-16 7:43 ` Michael Ellerman
2009-07-16 11:31 ` Josh Boyer
2009-07-16 13:16 ` Catalin Marinas
2009-07-16 17:52 ` Catalin Marinas
2009-07-17 0:29 ` Michael Ellerman
2009-07-17 8:26 ` Catalin Marinas [this message]
2009-07-17 8:32 ` Michael Ellerman
2009-07-17 8:41 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1247819195.32760.7.camel@pc1117.cambridge.arm.com \
--to=catalin.marinas@arm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).