Hi Jeremy,
It's good to hear some experience from the Valgrind world :-)
On 14/06/06, Jeremy Fitzhardinge <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
