[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.17-rc6 7/9] Remove some of the kmemleak false positives
    On 12/06/06, Ingo Molnar <> wrote:
    > * Catalin Marinas <> wrote:
    > > On 12/06/06, 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'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

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-13 00:27    [W:0.023 / U:48.752 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site