Nishanth Menon <[email protected]> writes: > 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 > > 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. Thanks, Kevin -- 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
