Messages in this thread |  | | | Date | Thu, 17 Aug 2006 09:28:03 +0100 | | From | "Catalin Marinas" <> | | Subject | Re: Some issues about the kernel memory leak detector: __scan_block() function |
| |
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 - 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/
|  |