>>-----Original Message----- >>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>Sent: Wednesday, August 25, 2010 2:55 AM >>To: Menon, Nishanth; Gopinath, Thara >>Cc: linux-omap; Artem Bityutskiy; Peter p2 De Schrijver >>Subject: Re: [PM-SR][PATCH 1/2 v2] omap3: sr: fix memory leak and simplify the code >> >>Nishanth Menon <nm@xxxxxx> writes: >> >>> From: Artem Bityutskiy <Artem.Bityutskiy@xxxxxxxxx> >>> >>> This patch fixes the following problem indicated by kmemleak: >>> >>> kmemleak: unreferenced object 0xdf93c280 (size 64): >>> kmemleak: backtrace: >>> kmemleak: [<c00df6d4>] create_object+0x104/0x200 >>> kmemleak: [<c00d7638>] kmem_cache_alloc+0xe4/0xf4 >>> kmemleak: [<c000fc38>] omap_devinit_smartreflex+0x44/0x244 >>> kmemleak: [<c003a33c>] do_one_initcall+0x5c/0x1b8 >>> kmemleak: [<c00083fc>] kernel_init+0x94/0x110 >>> kmemleak: [<c003ba04>] kernel_thread_exit+0x0/0x8 >>> >>> The reason is that 'omap_devinit_smartreflex()' allocates 'sr_data', >>> then passes it to 'omap_device_build()', which 'kmemdup()'s it and >>> uses the copy. But 'omap_devinit_smartreflex()' never frees 'sr_data'. >>> >>> This patch make 'sr_data' to be a stack variable, which eliminates >>> the memory leak and simplifies the code a bit. >>> >>> Cc: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> >>> Cc: Thara Gopinath <thara@xxxxxx>, >>> Cc: Peter p2 De Schrijver <peter.de-schrijver@xxxxxxxxx> >>> Cc: Nishanth Menon <nm@xxxxxx> >>> >>> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@xxxxxxxxx> >>> Acked-by: Nishanth Menon <nm@xxxxxx> >>> --- >>> Changes from V1: >>> rebased to latest pm-sr branch >>> default of sr_data set to 0 to make it equivalent to kzalloc >>> >>> NOTE: this probably should be squashed when being send upstream along with >>> rest of SR series >> >>Thara, you appear to have fixed this problem differently in your latest >>series. Looks like you just ensured kfree() was always done, correct? >> >>In the future, it would be helpful if you would reply to these proposed >>fixes on the list so we know if they are incorporated or handled >>differently. Yes.. you r correct.. I missed replying on this one. Sorry for the confusion. Will take care of this in future. It is indeed fixed by ensuring kfree() always. Regards, Thara -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
