Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1293923pxy; Fri, 23 Apr 2021 05:03:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxeBVkmnm6m1rGKoC5qvy5SEL8ckNij7YjXYVFSmeKxyGbZGHzBMVgdE7j0fAaMqUyErL9o X-Received: by 2002:a17:906:578a:: with SMTP id k10mr3825937ejq.425.1619179439107; Fri, 23 Apr 2021 05:03:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619179439; cv=none; d=google.com; s=arc-20160816; b=hdpngISIREa/bbyJGMHsqPfzjoVs0oPzhvFPvxCGh+TAQRL2MlBPkK7wAWeA/8ucPp +DTtCN4eQ9lkq+IJmCRCv2ZVCGv5DTRl5VYC0oHyNJlZplvrjtWbtU1hLflZIRQCkeiJ BxBIuoEWWH82bdN8ATACBXfb1KWWSQzCp22ebwT/bVO6TFYkBsXHllk/tFTNz1ZEhc6I dBPHjKJvwBSTXLki5x266ov/fO2vgcg0HLefKKTGa7hFehD1MPSehPDtjJ8aQRa/qOn6 nG5jBbPvi/du60lQ9lvN2Cn2KK17hx+Qsptaemf9W1dyTfpQMTxvnKHS9gWChHYtjo01 kqFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=OC4x/LZCsqMKwoLM1Y9KMddMinjhk0tMbTFAXST+890=; b=cdjLHfH2HYVwW8Bb9L2YZ7tIzpb+wrCQOghm0MvI1yLgMpkvWIldtkdKgkCklBRS13 79ix/DUroj6o0CYYmXivdzc98VwGsFmDmIS1Sli4iOr8/yXNBIX+YOFlfII9VtYtdr19 mnBtA0FC7F0g0CSvMU9Vd/k1TC93MbK3HhxyiBQ2HPiYLVhZImvpNUkFGznJdPrCsQOE g4El+pJ49AyJuGHAuVBV0vEf4Pf8kEAjkJsvOvxPOhKNfyOK7/aVACY+zHTLno0b3wVu pK5ri5vi4wWJ2WCBeVp2CEut6xsbfpTYHWNyU/57JOZ71+wBN7Extj/6E8QNJD4L8Uvl rcVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q16si4980632edr.479.2021.04.23.05.03.28; Fri, 23 Apr 2021 05:03:59 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229479AbhDWMC7 (ORCPT + 99 others); Fri, 23 Apr 2021 08:02:59 -0400 Received: from smtp06.smtpout.orange.fr ([80.12.242.128]:56399 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231472AbhDWMC4 (ORCPT ); Fri, 23 Apr 2021 08:02:56 -0400 Received: from [192.168.1.18] ([86.243.172.93]) by mwinf5d63 with ME id wC2J2400121Fzsu03C2JFL; Fri, 23 Apr 2021 14:02:19 +0200 X-ME-Helo: [192.168.1.18] X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Fri, 23 Apr 2021 14:02:19 +0200 X-ME-IP: 86.243.172.93 Subject: AW: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling path To: Walter Harms , "mturquette@baylibre.com" , "sboyd@kernel.org" , "gregory.clement@bootlin.com" , "thomas.petazzoni@free-electrons.com" Cc: "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kernel-janitors@vger.kernel.org" References: <27db232fdd14e14d493f29a5404d9e643f09cc96.1619157996.git.christophe.jaillet@wanadoo.fr> <3e38da0e86c045d3aefd46f375e8b48e@bfs.de> From: Christophe JAILLET Message-ID: Date: Fri, 23 Apr 2021 14:02:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <3e38da0e86c045d3aefd46f375e8b48e@bfs.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 23/04/2021 à 13:42, Walter Harms a écrit : > 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 > Gesendet: Freitag, 23. April 2021 08:25:01 > An: mturquette@baylibre.com; sboyd@kernel.org; gregory.clement@bootlin.com; thomas.petazzoni@free-electrons.com > Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-janitors@vger.kernel.org; Christophe JAILLET > Betreff: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling path > > WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/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 > --- > 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_node *node) > for_each_of_cpu_node(dn) { > struct clk_init_data init; > struct clk *clk; > - char *clk_name = kzalloc(5, GFP_KERNEL); > + char *clk_name; > int cpu, err; > > - if (WARN_ON(!clk_name)) > - goto bail_out; > - > err = of_property_read_u32(dn, "reg", &cpu); > if (WARN_ON(err)) > goto bail_out; > > - sprintf(clk_name, "cpu%d", cpu); > + clk_name = kasprintf(GFP_KERNEL, "cpu%d", cpu); > + if (WARN_ON(!clk_name)) { > + goto bail_out; > + } > > cpuclk[cpu].parent_name = of_clk_get_parent_name(node, 0); > cpuclk[cpu].clk_name = clk_name; > -- > 2.27.0 > >