Query regarding Kmemleak

[Smital Desai]

________________________________________
From: Jeff Haran [jharan at bytemobile.com]
Sent: Wednesday, February 01, 2012 6:00 AM
To: Smital Desai; Kernel Newbies
Subject: RE: Query regarding Kmemleak

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] 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 at kernelnewbies.org
> 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