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

["Catalin Marinas" <catalin.marinas@gmail.com>]

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