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

["Mauricio Lin" <mauriciolin@gmail.com>]

Hi Catalin,

On 8/17/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> 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.

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/