* Aaro Koskinen <[email protected]> [100208 04:29]: > The platform data allocated with kmalloc() will become unreachable once > the init is complete, so it should be freed. The problem was discovered > by kmemleak.
Looks like this is safe to do as platform_device_add_data does kmemdup on the data. BTW, if you want to create a version for 2.6.33, we should still have enough time to queue it as a fix. It's a very limited size leak though, but still a leak. Regards, Tony > Signed-off-by: Aaro Koskinen <[email protected]> > --- > arch/arm/mach-omap2/hsmmc.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c > index 1156b28..9ad2295 100644 > --- a/arch/arm/mach-omap2/hsmmc.c > +++ b/arch/arm/mach-omap2/hsmmc.c > @@ -145,6 +145,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info > *controllers) > { > struct omap2_hsmmc_info *c; > int nr_hsmmc = ARRAY_SIZE(hsmmc_data); > + int i; > > if (cpu_is_omap2430()) { > control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE; > @@ -171,7 +172,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info > *controllers) > GFP_KERNEL); > if (!mmc) { > pr_err("Cannot allocate memory for mmc device!\n"); > - return; > + goto done; > } > > if (c->name) > @@ -256,6 +257,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info > *controllers) > continue; > c->dev = mmc->dev; > } > + > +done: > + for (i = 0; i < nr_hsmmc; i++) > + kfree(hsmmc_data[i]); > } > > #endif > -- > 1.5.6.5 > -- 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
