On Thu, 8 Apr 2021 at 01:41, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Dmitry Baryshkov (2021-04-06 16:06:06) > > devm_clk_hw_register_fixed_factor_release(), the release function for > > the devm_clk_hw_register_fixed_factor(), calls > > clk_hw_unregister_fixed_factor(), which will kfree() the clock. However > > after that the devres functions will also kfree the allocated data, > > resulting in double free/memory corruption. Just call > > clk_hw_unregister() instead, leaving kfree() to devres code. > > > > Reported-by: Rob Clark <robdclark@xxxxxxxxxxxx> > > Cc: Daniel Palmer <daniel@xxxxxxxx> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > --- > > > > Stephen, this fix affects the DSI PHY rework. Do we have a chance of > > getting it into 5.12, otherwise there will be a cross-dependency between > > msm-next and clk-next. > > Think I can get this into the last fixes PR. One question though, I > think this follows the pattern that things like clk-divider.c use for > devm. Are those also broken? It looks so. See e.g. the devres_release() function. It calls (*release) callback, then it will kfree the resource. Also see Documentation/driver-api/driver-model/devres.rst, which does not kfree() in release functions. Do you wish for me to send all the fixes? -- With best wishes Dmitry
