> -----Original Message----- > From: Smital Desai [mailto:Smital.Desai@xxxxxxxxxxxxxxx] > Sent: Tuesday, January 31, 2012 5:47 PM > To: Jeff Haran; Kernel Newbies > Subject: RE: Query regarding Kmemleak > > ________________________________________ > From: Jeff Haran [jharan@xxxxxxxxxxxxxx] > Sent: Wednesday, February 01, 2012 6:00 AM > To: Smital Desai; Kernel Newbies > Subject: RE: Query regarding Kmemleak > > > -----Original Message----- > > From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx > [mailto:kernelnewbies- > > bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Smital Desai > > Sent: Tuesday, January 31, 2012 4:02 PM > > To: Kernel Newbies > > Subject: Query regarding Kmemleak > > > > Hello , > > > > I am just trying to understand Kmemleak support. > > > > In a test program , allocating some memory using and vmalloc > () and > > freeing it in exit () routine. > > But when i run a kmemleak , It reports this as a leak. > > > > But isn't it a generic reuirement to allocate something for > the lifetime of > > the module and free when we remove the module. ? Can somebody > > explain ? > > > > I have provided the kmemleak output and my test program > below. > > > > Thanks, > > Smital Desai > > > > > > > ========================================================== > > ======================= > > > > cat /sys/kernel/debug/memleak > > > > unreferenced object 0xe1b18000 (size 512): > > comm "insmod", pid 1066, jiffies 4294953148 (age 54.630s) > > hex dump (first 32 bytes): > > 36 1c 00 00 02 16 00 00 3c 1c 00 00 02 16 00 00 6.......<....... > > 43 1c 00 00 02 16 00 00 4f 1c 00 00 02 16 00 00 C.......O....... > > backtrace: > > [<c0234ecc>] __vmalloc_node_range+0x1a8/0x1d0 > > [<c0234f2c>] __vmalloc_node+0x38/0x44 > > [<c023507c>] vmalloc+0x28/0x30 > > [<bf00200c>] 0xbf00200c > > [<c0100458>] do_one_initcall+0x94/0x164 > > [<c01d639c>] sys_init_module+0x70/0x190 > > [<c0105d60>] ret_fast_syscall+0x0/0x30 > > [<ffffffff>] 0xffffffff > > unreferenced object 0xe1b1a000 (size 512): > > comm "insmod", pid 1066, jiffies 4294953148 (age 54.630s) > > hex dump (first 32 bytes): > > 00 00 00 00 00 2c 00 00 00 00 00 00 2a 03 00 00 .....,......*... > > 00 00 00 00 00 2c 00 00 bc 00 00 00 02 2e 00 00 .....,.......... > > backtrace: > > [<c0234ecc>] __vmalloc_node_range+0x1a8/0x1d0 > > [<c0234f2c>] __vmalloc_node+0x38/0x44 > > [<c023507c>] vmalloc+0x28/0x30 > > [<bf00201c>] 0xbf00201c > > [<c0100458>] do_one_initcall+0x94/0x164 > > [<c01d639c>] sys_init_module+0x70/0x190 > > [<c0105d60>] ret_fast_syscall+0x0/0x30 > > [<ffffffff>] 0xffffffff > > > ========================================================== > > =========================== > > > > > > > > "test.c" > > > ========================================================== > > ======================== > > #include <linux/init.h> > > #include <linux/kernel.h> > > #include <linux/module.h> > > #include <linux/kmemleak.h> > > > > char *ptr1, *ptr2; > > > > /* > > * Some very simple testing. This function needs to be extended for > > * proper testing. > > */ > > static int __init kmemleak_test_init(void) > > { > > ptr1 = vmalloc(512); > > ptr2 = vmalloc(512); > > > > return 0; > > } > > module_init(kmemleak_test_init); > > > > static void __exit kmemleak_test_exit(void) > > { > > vfree(ptr1); > > vfree(ptr2); > > } > > module_exit(kmemleak_test_exit); > > > > MODULE_LICENSE("GPL"); > > > ========================================================== > > ======================== > > > > > > > > Thanks and Regard > > Smital Desai > > > > The contents of this e-mail and any attachment(s) may contain > confidential > > or privileged information for the intended recipient(s). Unintended > > recipients are prohibited from taking action on the basis of > information in this > > e-mail and using or disseminating the information, and must notify > the > > sender and delete it from their system. L&T Infotech will not accept > > responsibility or liability for the accuracy or completeness of, or > the presence > > of any virus or disabling code in this e-mail" > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies@xxxxxxxxxxxxxxxxx > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > >>Just to be clear: > > >>Did you rmmod your module before doing the cat on > >>/sys/kernel/debug/memleak? > > >>If not, I think the above output of memleak is what would be expected. > > >>Jeff Haran > > > Hello Jeff, > > Yeh , you are correct and i didn't remove the module . > But in that case what if module stays there for the system's life time > keeping the allocated memory , it will get reported by kmemleak as potential > __leak__ . ( Which essentially is false postitive ) > > And the case i am mentioning can be pretty much the requirement of > atleast few drivers which keep memory allocated for system's lifetime , how > to avoid this false postitive in such cases .? > > Thanks, > Smital Desai I don't see how the system could distinguish this memory allocation from a memory leak, but not being an expert on the topic I look forward to being corrected by others more knowledgeable. 8^) A "memory leak" after all is just allocated memory that the coder forgets to free when his code is otherwise done with and with a kernel module something on the outside can't really know the module is done with it until the module is rmmod'ed. There's no lifetime specified when you call vmalloc(). I've seen people who were tasked with finding memory leaks do tricks like keep track of the address of every allocated memory block and then periodically scan through memory looking to see if those addresses exists anywhere, the theory being that if one doesn't then the subject code has forgotten about the memory allocation and is thus highly likely to be a leak. But I don't see how one could ever eliminate all false positives. Jeff Haran _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
