lkml.org 
[lkml]   [2006]   [Jun]   [12]   [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

* Catalin Marinas <catalin.marinas@gmail.com> wrote:

> On 12/06/06, Ingo Molnar <mingo@elte.hu> 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'll document them in both Documentation/kmemleak.txt and inside the
> code. If I implement the "any pointer inside the block" method, all
> the memleak_padding() false positives will disappear.

i dont know - i feel uneasy about the 'any pointer' method - it has a
high potential for false negatives, especially for structures that
contain strings (or other random data), etc.

did you consider the tracking of the types of allocated blocks
explicitly? I'd expect that most blocks dont have pointers embedded in
them that point to allocated blocks. For the ones that do, the
allocation could be extended with the type information. For each
affected type, we could annotate the structures themselves with offset
information. How intrusive would such a method be?

Ingo
-
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-12 21:25    [W:0.093 / U:2.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site