* Catalin Marinas <[email protected]> wrote:
> My opinion is not to implement the "anywhere inside a block" method as
> it would increase the risk of false negatives with a little benefit
> (removing some false positive notifications, probably less than 30).
agreed.
> To the other extreme is Ingo's suggestion of using exact type
> identification but I don't think this would be acceptable for the
> kernel as it would to modify all the memory alloc calls in the kernel
> to either pass an additional parameter (the type id) or another
> post-allocation call to kmemleak to update the id.
passing in the type ID wouldnt be that bad and it would have other
advantages as well: for example we could do strict type-checking of
allocation size versus type-we-use-it-for.
As long as the conversion is gradual i think we could try this. I.e.
we'd default to 'no ID passed', and in that case we would fall back to
the size-based method and generate an ID out of the structure size.
> Anyway, the current implementation (I'll update it for 2.6.17) detects
> real memory leaks. I suspect that a wide range of leaks would be
> covered if it is used on different platforms and different conditions.
btw., what leaks were found so far? I know about the ACPI one - any
other ones?
Ingo
-
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]
