Re: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives

["Catalin Marinas" <catalin.marinas@gmail.com>]

Hi Jeremy,

It's good to hear some experience from the Valgrind world :-)

On 14/06/06, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Ingo Molnar wrote:
> > But it's not just about the amount of false negatives, but also about
> > the overhead of scanning. You are concentrated on embedded systems with
> > small RAM - but most of the testers will be running this with at last
> > 1GB of RAM - which is _alot_ of memory to scan.
> >
> It seems to me that most types with any pointers are fairly
> pointer-dense.

There seem to be many structures containing mostly data and only one
or two list_head structures with pointers. Here only the list_head
member would need to be scanned.

> False pointers in kernel allocations can be avoided in a few ways.  The
> first, obviously, is the make sure all memory is initialized to a known
> non-pointer value.

This is done already by the DEBUG_SLAB configuration.

> The second is to ignore pointers which don't point
> near the start of an allocated region (possibly unsafe in the kernel,
> depending on the definition of "near").

Kmemleak only accepts values that point to either the beginning of the
allocated block or to one of its aliases (a offset from the beginning
which is determined from the container_of() usages on that
structure/member - most of the list usages). There is a discussion one
whether to allow a value to point anywhere inside a block but I would
need to investigate the risks.

> You can get more sophisticated
> from there; the Boehm GC keeps tracks of things which look like pointers
> but turn out not to be (they don't point to allocated memory); it marks
> that memory as being unusable, so that the false pointer won't get
> mistaken for one later on, with the obvious risk that lots of false
> pointers can render large parts of your heap address space unusable.

This would increase the overhead as in my tests around 15% of all the
values scanned look like pointers (i.e. between PAGE_OFFSET and
PAGE_OFFSET + ram_size).

> There's some risk of false positives.  You can imagine cases where the
> last reference to a block is transformed into a bus address, and in
> effect a piece of hardware holds it.  You don't get to know about the
> pointer until the hardware gives it back.

This is pretty rare and you can easily tell kmemleak to ignore it.

--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/