Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Walter Harms <wharms@bfs.de>
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        "mturquette@baylibre.com" <mturquette@baylibre.com>,
        "sboyd@kernel.org" <sboyd@kernel.org>,
        "gregory.clement@bootlin.com" <gregory.clement@bootlin.com>,
        "thomas.petazzoni@free-electrons.com" 
        <thomas.petazzoni@free-electrons.com>
CC:     "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org>
Subject: AW: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling
 path
Thread-Topic: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling
 path
Thread-Index: AQHXOAlra2sQAacEjUWcDYHHPtnRKKrB+sUc///ko4CAAFZ1Wg==
Date:   Fri, 23 Apr 2021 15:34:37 +0000
Message-ID: <ec52f27bb33f419481653fe1a0b35419@bfs.de>
References: <cover.1619157996.git.christophe.jaillet@wanadoo.fr>
 <27db232fdd14e14d493f29a5404d9e643f09cc96.1619157996.git.christophe.jaillet@wanadoo.fr>
 <3e38da0e86c045d3aefd46f375e8b48e@bfs.de>,<f26e2ad3-d1b8-de96-febe-5b8f52abdf8f@wanadoo.fr>
In-Reply-To: <f26e2ad3-d1b8-de96-febe-5b8f52abdf8f@wanadoo.fr>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

yep,
there was a patch containing while()/free(), i guessed the comment
was accidentaly copied (or do i mixup something ?)

forget about it, the comment was confusing me.=20
IMHO it is the wrong way around.
I would say:

 sightly rearrange the code:
    - use kasprintf instead of kzalloc/sprintf to simplify code and avoid a
      magic number
If an error occurs in the for_each loop, clk_name must be freed.
 goto bail_out;
=20
as side effect more that 9 clk_cpu are now correctly shown.

hope that helps,

re,
 wh
________________________________________
Von: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Gesendet: Freitag, 23. April 2021 14:02:17
An: Walter Harms; mturquette@baylibre.com; sboyd@kernel.org; gregory.clemen=
t@bootlin.com; thomas.petazzoni@free-electrons.com
Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-janitor=
s@vger.kernel.org
Betreff: AW: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling=
 path

WARNUNG: Diese E-Mail kam von au=DFerhalb der Organisation. Klicken Sie nic=
ht auf Links oder =F6ffnen Sie keine Anh=E4nge, es sei denn, Sie kennen den=
/die Absender*in und wissen, dass der Inhalt sicher ist.


Le 23/04/2021 =E0 13:42, Walter Harms a =E9crit :
> nitpicking:
>   clk_name could be replaced with cpuclk[cpu].clk_name

Agreed, Thx.
I'll wait a few days to see if there are other comments before sending a
v2. (especially if 4/4 is correct or not)
I'll also add "clk-cpu:" after "clk: mvebu:"

> and the commit msg is from the other patch (free  cpuclk[cpu].clk_name)
>

But here, I don't follow you.
What do you mean? Which other patch?

Do you mean that the commit message has to be updated accordingly?
(ie: s/clk_name/cpuclk[cpu].clk_name/ must be freed)


> jm2c,
>
> re,
>   wh
> ________________________________________
> Von: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Gesendet: Freitag, 23. April 2021 08:25:01
> An: mturquette@baylibre.com; sboyd@kernel.org; gregory.clement@bootlin.co=
m; thomas.petazzoni@free-electrons.com
> Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-janit=
ors@vger.kernel.org; Christophe JAILLET
> Betreff: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling p=
ath
>
> WARNUNG: Diese E-Mail kam von au=DFerhalb der Organisation. Klicken Sie n=
icht auf Links oder =F6ffnen Sie keine Anh=E4nge, es sei denn, Sie kennen d=
en/die Absender*in und wissen, dass der Inhalt sicher ist.
>
>
> If an error occurs in the for_each loop, clk_name must be freed.
>
> In order to do so, sightly rearrange the code:
>     - move the allocation to simplify error handling
>     - use kasprintf instead of kzalloc/sprintf to simplify code and avoid=
 a
>       magic number
>
> Fixes: ab8ba01b3fe5 ("clk: mvebu: add armada-370-xp CPU specific clocks")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> The { } around the 1 line block after kasprintf is intentional and makes
> sense with 2/2
> ---
>   drivers/clk/mvebu/clk-cpu.c | 10 +++++-----
>   1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> index c2af3395cf13..a11d7273fcc7 100644
> --- a/drivers/clk/mvebu/clk-cpu.c
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -195,17 +195,17 @@ static void __init of_cpu_clk_setup(struct device_n=
ode *node)
>          for_each_of_cpu_node(dn) {
>                  struct clk_init_data init;
>                  struct clk *clk;
> -               char *clk_name =3D kzalloc(5, GFP_KERNEL);
> +               char *clk_name;
>                  int cpu, err;
>
> -               if (WARN_ON(!clk_name))
> -                       goto bail_out;
> -
>                  err =3D of_property_read_u32(dn, "reg", &cpu);
>                  if (WARN_ON(err))
>                          goto bail_out;
>
> -               sprintf(clk_name, "cpu%d", cpu);
> +               clk_name =3D kasprintf(GFP_KERNEL, "cpu%d", cpu);
> +               if (WARN_ON(!clk_name)) {
> +                       goto bail_out;
> +               }
>
>                  cpuclk[cpu].parent_name =3D of_clk_get_parent_name(node,=
 0);
>                  cpuclk[cpu].clk_name =3D clk_name;
> --
> 2.27.0
>
>