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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux