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
-
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]
