On 12/06/06, Ingo Molnar <[email protected]> wrote:
* Catalin Marinas <[email protected]> wrote:
> On 12/06/06, Ingo Molnar <[email protected]> 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 [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]
