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. Thanks, Kevin -- 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
