On Fri, 2010-07-09 at 17:04 +0200, ext Nishanth Menon wrote: > From: Artem Bityutskiy <[email protected]> > > 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 <[email protected]> > Cc: Thara Gopinath <[email protected]>, > Cc: Peter p2 De Schrijver <[email protected]> > Cc: Nishanth Menon <[email protected]> > > Signed-off-by: Artem Bityutskiy <[email protected]> > Acked-by: Nishanth Menon <[email protected]> > --- > Changes from V1: > rebased to latest pm-sr branch > default of sr_data set to 0 to make it equivalent to kzalloc
Oh, right. Thanks for fixing! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
