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
On 12/06/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * 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.

That's my concern as well. The advantage is that it simplifies
kmemleak but I can't tell how good the detection would be. I can add
some code to the current implementation to show how many values (32
bit aligned) found during scanning look like valid pointers (i.e.
PAGE_OFFSET < x < PAGE_OFFSET + ram_size) but cannot be found in the
radix_tree. It might not be that bad (I'll post tomorrow some
statistics).

> 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?

Do you mean that when scanning it should only consider at the pointer
members in a structure? I don't think this can be easily achieved
because of the amount of structures in the kernel. There are places
where a pointer is stored as a long. There is also no way in C to
quantify the type of an object (similar to "typeid" in C++). The
closest approximation I could get was the size.

--
Catalin
-
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-13 00:27    [W:0.496 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site