Thread (7 messages) flat view 7 messages, 4 authors, 2009-08-20

Re: [PATCH] Add kmemleak annotations to lmb.c

From: Michael Ellerman <hidden>
Date: 2009-08-20 06:01:38

On Fri, 2009-08-14 at 22:57 +0100, Catalin Marinas wrote:
On Fri, 2009-08-14 at 12:49 -0700, David Miller wrote:
quoted
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 14 Aug 2009 17:56:40 +1000
quoted
On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
quoted
On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
quoted
We don't actually want kmemleak to track the lmb allocations, so we
pass min_count as 0. However telling kmemleak about lmb allocations
allows it to scan that memory for pointers to other memory that is
tracked by kmemleak, ie. slab allocations etc.
Looks alright to me (though I haven't tested it). You can add a
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Actually, Milton pointed to me that we may not want to allow all
LMB chunks to be scanned by kmemleaks, things like the DART hole
that's taken out of the linear mapping for example may need to
be avoided, though I'm not sure what would be the right way to
do it.
I think that annotating LMB for kmemleak may be more problems
that it's worth.
BTW, are there many LMB allocations used for storing pointers to other
objects? If not, it may be worth just annotating those with
kmemleak_alloc() if you get false positives.
Yeah I think that's probably the safer approach. As Dave says even if
there's nothing obvious, lmb is used for very early allocs which are
more likely to be "special" and cause problems - and only when someone
boots with kmemleak enabled. So we're better to explicitly mark things
we want scanned.

cheers

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help