Re: Some issues about the kernel memory leak detector: __scan_block() function

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

Hi Mauricio,

On 16/08/06, Mauricio Lin <mauriciolin@gmail.com> wrote:
> Let's suppose the a kmalloc() was executed without storing the
> returned pointer to the memory area and its fictitious returned value
> would be the address 0xb7d73000 as:
>
> kmalloc(32, GFP_KERNEL);  // Cause memory leak
>
> Is there any possibility the __scan_block() scans a memory block that
> contains the memory area allocated by the previous kmalloc?

That's what the memleak-test module does.

Yes, there is a chance and this is called a false negative. If there
is a (non-)pointer location having this value (especially the stack),
it won't be reported. However, these locations might change and at
some point you will get the leak reported.

To reduce the false negatives, I'll have to eliminate the stacks
scanning completely (and make sure there are no false positives
reported for pointers on the stack). Another improvement is to only
look at the places that would have pointers in a structure (both
Ingo's ideas). The latter is a bit more complicated but I could use
the compiler-generated data (-fdump-translation-unit) to identify the
structures and their members. It also requires some API changes to
allow exact type identification.

Anyway, I'll look into implementing the above after I sort out some
locking issues (which might cause deadlocks on SMP systems) with the
kmemleak re-entrancy.

-- 
Catalin