Re: [PATCH 2.6.17-rc4 6/6] Remove some of the kmemleak false positives

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

Pekka Enberg wrote:
> On 5/13/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
>> There are allocations for which the main pointer cannot be found but they
>> are not memory leaks. This patch fixes some of them.
> 
> Why can't they be found? How many false positives are you expecting?

The tool scans the data section and kernel stacks for pointers. The
referred blocks are scanned as well. If a block address is not found in
all the scanned memory, it is considered unreferable or orphan (the
tracing garbage collection algorithm) and reported. There are some
memory blocks which get allocated but the address to their beginning is
discarded as the kernel doesn't need to free them (it happens with some
allocations during the booting process).

Another false positive is that the pointer to the beginning of the block
is determined by the kernel at run-time via the container_of macro or
some other method. KMemLeak currently supports up to two nested
container_of macros.

Yet another false positive can be caused by allocation of a size that
differs from the structure's size (kmalloc(sizeof(struct...) + ...)) and
kmemleak cannot properly determine the container_of aliases. One example
is the platform_device_alloc function and a false positive is in
add_pcspkr in arch/i386/kernel/setup.c.

I'll do more testing and post a new version next week (which will
include the suggestions I received so far).

Catalin