lkml.org 
[lkml]   [2006]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives
Ingo Molnar wrote:
> For a GC a false negative is no big problem - it will reduce the
> efficiency of the GC a bit, but that's all. For leak detection, if we
> happen to have a persistent false pointer in .data (or any other
> persistently allocated memory), it may prevent the detection of a leak
> permanently - at least for that bootup. Statistically it could still be
> found on other systems, but it would be better to have a design that
> will eventually lead to having no false negatives.
>
> 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's not much point in trying to skip a couple of
non-pointers nested among a dozen others; once you've worn the cost of
pulling in the cache line there's not much else to worry about. The
most useful thing is to distinguish between completely pointerless
allocations and allocations which have pointers. Pointerless
allocations are generally just data (strings, numbers, user data), and
so are a waste of effort to scan, and possibly full of false pointers.
In the kernel, you could probably do it by making it a property of
slabs, assume all kmalloc allocations are pointerful (perhaps add
GFP_POINTERLESS), and make sure all user-data pages are considered
pointerless.

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. 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"). 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.

In general, false pointers aren't a huge problem. They'll generally
lead to a bounded number of allocations being unreported as leaks; its
highly unlikely that a large heap graph will remain hidden from a leak
checker forever; espectially since kernel pointers are fairly unlike
other kinds of data (large enough to not be aliased to most normal
integer values, don't look like strings, and there are no FP numbers in
the kernel).

> (But, if it's not possible to implement it in a sane manner then that's
> not an issue either - it's rather the false positives that must be
> avoided.)
>

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. You might want a GFP_ROOT
flag (or whatever), to mark a block as being always referenced in order
to suppress these cases.

> there are a couple of possibilities.
>
> If the ID is string based then you dont even have to touch containr_of()
> calls - just generate the typename string via the "#y" stringification
> preprocessor directive, where 'y' is the second parameter of
> container_of().
> [...]
> it needs some thought, but this way it's quite possible to build-time
> map types to IDs.
>

This seems pretty over-engineered. I wouldn't go this far unless you're
actually seeing performance/correctness problems, and a simple
with/without pointers flag isn't enough. It also doesn't address the
most troublesome source of false pointers: stacks. There is all sorts
of junk lying around on stacks, and you can have an old dead pointer
sitting there pinning old dead memory for a long time.

J
-
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/

\
 
 \ /
  Last update: 2006-06-14 07:56    [W:0.178 / U:11.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site