Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3081761pxb; Mon, 9 Nov 2020 01:53:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwI+5zh4IQrVeHSsELSYelKYFj0zh4YFKy6twPqHj7kxOt7Qyf/IlK04eo1y6mukmNCgLi X-Received: by 2002:a17:906:fa0a:: with SMTP id lo10mr9761023ejb.309.1604915608056; Mon, 09 Nov 2020 01:53:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604915608; cv=none; d=google.com; s=arc-20160816; b=U/O1hYrFf4En/8ONlkyiJC8k0JwlJEkpLx0Gm++fx03jvsDXZ0pONi7FkvwU7YOGRc ZZu4K3FrsLjjpIt/9jWKnzJ2umCYMSHBK9b4ogCHB0du7Hhi3tnGJ6dc3NYaOL1yPG7L /HmxsC5ajhOHbYR2FH1TSjW66cEmAFHLrHNdOWVGAkP+RdY/52N7YZV3bkUGPgEEgi3y d7xA0M0j8x46RHip6l8bSzzOhnM2GqaCo5nG3wxJTbRqysMCspnFyP72wAf/cLaYPDya hCm1AQke2Npry1EVEH6uO+qgLgTMoSp/vtetqm4PES6846tpwyHPXNd3srOTXXqNnAdS 3eFA== 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=vuAjB8oo3E0qnngMquEpqKiUhiEcLbupotY8GObN3zA=; b=ESA1ABOFpbKK0Okze7xhKwbxXmnNGJw5YZEzI9qkVV3z3Gbm/E9LN1zCyPRajdaohV yMR1M5eFuN/mLIpmpVmDpsaWA4k7PO0FFv7KKh7+YXJTb8zSIgy6A5kbiiOxdjFkvvzg wgF88G2jpTLlvzqAtoQUY3wEVZC99MnKjN49a2zaXUwwG3ZzzYJCgHU7W7/8+Pd6u1Mo rL8Wn9KaNplACSd37R+tbwx7TUYi2SfNPB0Hy7jLLjc/7bOvO1nAMfuTLlLzGJDRyMM2 Ra90i91beyhyQ99WQZJvEH0qx70dy4NvIGnXut7SEzWxpSnSkS8UC4aElzm3qE8tvPKf cQwg== 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 ca10si6367663edb.170.2020.11.09.01.53.05; Mon, 09 Nov 2020 01:53:28 -0800 (PST) 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 S1729050AbgKIJv0 (ORCPT + 99 others); Mon, 9 Nov 2020 04:51:26 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:2365 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728866AbgKIJvZ (ORCPT ); Mon, 9 Nov 2020 04:51:25 -0500 Received: from dggeme755-chm.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4CV5q50hkzz52T4; Mon, 9 Nov 2020 17:51:13 +0800 (CST) Received: from [10.140.157.68] (10.140.157.68) by dggeme755-chm.china.huawei.com (10.3.19.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 9 Nov 2020 17:51:22 +0800 Subject: Re: [PATCH] clk: hisilicon: Fix the memory leak issues To: Markus Elfring , CC: , , Michael Turquette , Stephen Boyd References: <20201106203525.9991-1-gengdongjiu@huawei.com> <30b24944-1315-b6de-5290-28b9d7842610@web.de> From: Dongjiu Geng Message-ID: Date: Mon, 9 Nov 2020 17:51:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <30b24944-1315-b6de-5290-28b9d7842610@web.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.140.157.68] X-ClientProxiedBy: dggeme704-chm.china.huawei.com (10.1.199.100) To dggeme755-chm.china.huawei.com (10.3.19.101) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/11/8 21:55, Markus Elfring wrote: >> When return errors, … > > I would find an other wording more appropriate for this change description. > > >> …, so fix this issue. > > I suggest to replace this information by an other imperative wording > and the tag “Fixes”. OK, done, I have submitted the version 2 patch > > > … >> +++ b/drivers/clk/hisilicon/clk-hi3620.c >> @@ -463,12 +463,16 @@ static void __init hi3620_mmc_clk_init(struct device_node *node) >> } >> >> clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL); >> - if (WARN_ON(!clk_data)) >> + if (WARN_ON(!clk_data)) { >> + iounmap(base); > > Can a statement like “goto unmap_io;” make sense here? OK, I have changed it. > > >> return; >> + } >> >> clk_data->clks = kcalloc(num, sizeof(*clk_data->clks), GFP_KERNEL); >> - if (!clk_data->clks) >> + if (!clk_data->clks) { > > How do you think about to add the function call “kfree(clk_data)” in this if branch? OK, I have changed it. > > > … >> +++ b/drivers/clk/hisilicon/clk.c > … > if (!base) { > pr_err("%s: failed to map clock registers\n", __func__); > - goto err; > + return NULL; > > >> @@ -69,8 +69,10 @@ struct hisi_clock_data *hisi_clk_init(struct device_node *np, >> } >> >> clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL); >> - if (!clk_data) >> + if (!clk_data) { >> + iounmap(base); >> goto err; > > Please use another jump target. OK, thanks, I have changed it. > > >> @@ -82,6 +84,7 @@ struct hisi_clock_data *hisi_clk_init(struct device_node *np, >> of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data->clk_data); >> return clk_data; >> err_data: >> + iounmap(base); >> kfree(clk_data); >> err: >> return NULL; > > I propose to apply the following code variant. OK, have modified. > > return clk_data; > > free_clk_data: > kfree(clk_data); > unmap_io: > iounmap(base); > return NULL; > > > Regards, > Markus > . >