Query regarding Kmemleak
Jeff Haran
jharan at bytemobile.com
Tue Jan 31 21:06:48 EST 2012
> -----Original Message-----
> From: Smital Desai [mailto:Smital.Desai at lntinfotech.com]
> Sent: Tuesday, January 31, 2012 5:47 PM
> To: Jeff Haran; Kernel Newbies
> Subject: RE: Query regarding Kmemleak
>
> ________________________________________
> 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
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
More information about the Kernelnewbies
mailing list