Re: [PATCH] regmap: Properly free allocated name for regmap_config of syscon

[Kefeng Wang]

On 2020/11/10 16:47, Marc Zyngier wrote:
> On 2020-11-10 01:35, Kefeng Wang wrote:
> > On 2020/11/10 1:23, Mark Brown wrote:
> > > On Mon, Nov 09, 2020 at 07:58:16PM +0800, Kefeng Wang wrote:
> > Hi Marc,  the regmap debugfs will duplicate a name in 
> > regmap_set_name(), and
> >
> > syscon_config.name won't be used in syscon,  so your following patch
> > doesn't seem
> >
> > to be necessary,  right ? Please correct me if I'm wrong, thanks.
>
> It was certainly necessary at the time when I wrote the patch, as it
> was fixing some obvious memory corruption (use after free).
>
> It is very possible that the flow has been reorganised since, as the
> following commit hints at:
>
> commit e15d7f2b81d2e7d93115d46fa931b366c1cdebc2
> Author: Suman Anna <s-anna@xxxxxx>
> Date:   Mon Jul 27 16:10:08 2020 -0500
>
>     mfd: syscon: Use a unique name with regmap_config
>
>     The DT node full name is currently being used in regmap_config
>     which in turn is used to create the regmap debugfs directories.
>     This name however is not guaranteed to be unique and the regmap
>     debugfs registration can fail in the cases where the syscon nodes
>     have the same unit-address but are present in different DT node
>     hierarchies. Replace this logic using the syscon reg resource
>     address instead (inspired from logic used while creating platform
>     devices) to ensure a unique name is given for each syscon.
>
>     Signed-off-by: Suman Anna <s-anna@xxxxxx>
>     Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx>
>     Signed-off-by: Lee Jones <lee.jones@xxxxxxxxxx>
>
> I suggest you come up with a more complete analysis of the problem
> and how it came to be.

I check the history of above patch[1],

"The regmap name is expected to be managed by the caller and should be
live as long as the regmap is live, it is almost always static data."

so keep it as your patch said, thanks.

[1] 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20200727211008.24225-1-s-anna@xxxxxx/#23575471


>         M.