Hi Catalin,
I have tested your latest kernel memory leak detector on my ARM device
and for curiosity I have checked some part of your patch to figure out
how the memory is scanned and compared to radix tree for detecting
orphan pointer.
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?
If this is possible, during the "for (ptr = start; ptr < end; ptr++)
{} " loop in the __scan_block(), the ptr variable can assume the
address 0xb7d73000 and the radix_tree_lookup() returns the
corresponding memleak_pointer and thus such pointer to this memory
area is not considered orphan (indeed it is an orphan pointer), right?
BR,
Mauricio Lin.
Hi Mauricio,
On 16/08/06, Mauricio Lin <[email protected]> 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
Hi Catalin,
On 8/17/06, Catalin Marinas <[email protected]> wrote:
> Hi Mauricio,
>
> On 16/08/06, Mauricio Lin <[email protected]> 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.
Do you mean that the (non-)pointer location might be moved to another
memory location?
Let's say that the fictitious address 0xb7d73000 can be changed to
another memory address, right?
BR,
Mauricio Lin.
On 17/08/06, Mauricio Lin <[email protected]> wrote:
> On 8/17/06, Catalin Marinas <[email protected]> wrote:
> > On 16/08/06, Mauricio Lin <[email protected]> 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.
>
> Do you mean that the (non-)pointer location might be moved to another
> memory location?
No, I mean that the value at that location might be changed. Let's say
you have a location in the data section or in another kmalloc'ed block
(which is trackable from the data section) which has value 0xb7d73000.
If this just happened to be random data, there is a chance that it
will be modified to something else and a new scan won't find it
anymore.
--
Catalin