Hi Ingo,
On Mon, 12 Jun 2006, Ingo Molnar wrote:
> While it's always good to reduce the amount of false positives, i dont
> think it's unacceptable for inclusion right now. A few dozen annotations
> out of 7000+ allocation call sites isnt a big maintainance problem - and
> the benefits of automatic leak-checking are really huge.
Did you look at the call sites? It seems clear that kmemleak doesn't
support existing kernel coding style yet (see below) which means we're not
covering all false positives.
On Mon, 12 Jun 2006, Ingo Molnar wrote:
> What i'd like to see though are clear explanations about why an
> allocation is not considered a leak, in terms of comments added to the
> code. That will also help us reduce the number of annotations later on.
I found at least two unacceptable false positive classes:
- arch/i386/kernel/setup.c:
False positive because res pointer is stored in a global instance of
struct resource.
- drivers/base/platform.c and fs/ext3/dir.c:
False positive because we allocate memory for struct + some extra
stuff.
At least the latter can be fixed as outlined by Catalin in another mail.
Pekka
-
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]
