Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5873998imm; Mon, 27 Aug 2018 06:00:12 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ1/f6meCV10opaY1GyS65kS7Iockz9vzJYVaMBdow7LbrbX/gST4VHXY9tcK6zt+bXqJe+ X-Received: by 2002:a17:902:261:: with SMTP id 88-v6mr13033872plc.331.1535374812430; Mon, 27 Aug 2018 06:00:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535374812; cv=none; d=google.com; s=arc-20160816; b=P5t78X5fRm77LQc3bne29imUsX9Ne0im64uOZzWBKOR/XDXFcvl4aFFoTKtsxnXDFs WhFlpbCbm0B+rkBeYRZTaxbo5KjfwbnwZ+u7AjuTbJyMQ+xuRVjT37l0Xq9SvreALnKl Ph3Dc0J9LpQxgV5v3c3b76YgYKXFQN0rCzRRZ6K6XJAZmRaN78J3RHtghqLOg/r9rB2Y 7wrQY4mmMaa8KaM72k4wcKYpK1Hoe04Vbl1b7leEh8WFw30vxdMP2axLh2bu6/Tf7O7d mQHrR3IF1ScbF3IOC+iJ4JkYRkwyO4raOGRY37pzrut9H1EDr207quAOfjkCn7ZDc+1I j6RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ebhA6mp22PxLzUQAFm1Da376tltX3rYnvGhJ4FPB9/o=; b=BGL/3VifUCgSNrsveCULZ26yBZmCPTxCVZXIjKS1NTlRTa7YQZvUzDKCFay6QI4rry guvqr6I25DPIm2SoozajiH1HA76ppEDK0Vuns8cTzNDlNsnQgROXaaqXPuThK/nIYXTP XIjIcfH9dmmZNvmOr2d6lyzQ4bbSKcW40mlo4hNAKXmRHhCell8v1WrtQIFeurZ5V0km 8zaGykJ2IV0JTSEX66jJYaxO2s25FFz7tvLRlhD/SMFTsZUvv0xuhk6MJ5yQ4gScSSZQ PCrIMEXZEC0PqoosjJcInc+MftnJzuMzm0ZzFuslLwEL4jlWkqd4/7b+QchhvdGzkJYx Zt0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=qJ4qp+uS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a64-v6si16408085pfb.224.2018.08.27.05.59.55; Mon, 27 Aug 2018 06:00:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=qJ4qp+uS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726987AbeH0QpV (ORCPT + 99 others); Mon, 27 Aug 2018 12:45:21 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:36164 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbeH0QpV (ORCPT ); Mon, 27 Aug 2018 12:45:21 -0400 Received: by mail-io0-f196.google.com with SMTP id q5-v6so9477641iop.3 for ; Mon, 27 Aug 2018 05:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ebhA6mp22PxLzUQAFm1Da376tltX3rYnvGhJ4FPB9/o=; b=qJ4qp+uS7pXdAicfjnU92YkoweqU91A4lfEjA7Xl7GB22URUwn+NHgr9TG6w/go5I1 2ln7mipDqWDRE5ruMM3YkfeM+xamcLzyqzrbwfNrtb9661qmpnkM0K7g46SxuDT5GRWX +8ZAxrsd5UYhRTOwGEEHK/sJd2anUMyLSDcnjkDkwL701jtUEm62F/kqZxZRw7AzD+J+ jPEaSXZwMdT4zX2QPNBEYxuzmRFXi+vSDUWjlhYNmrPl2rI+TRroJSbSC8DAKvO3qArT fj+vggc1CM3zqPcUZLMlHgPzAVOTSFeMOVbsnviPERalAdytzzQIh9SqkhOK92i18DcN iPdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ebhA6mp22PxLzUQAFm1Da376tltX3rYnvGhJ4FPB9/o=; b=UkohIetbMKsxzNqX4es5Hsb/akksBqT+kBrpJEYsQ4QL8BOixni1aYokBaokI1h++1 LQkqYi8B0TNjDp8R+v58gXGPpRIyzkv/jznFbsNE36Yku1Wgd9ZyJePRJo53FV6vfjbZ kHvK1CnLgr1mBZf3N5ShgLRLR4tsEWK+dYpnAJG8A3aNT5iOgrTnCBCO8Ikt6/AMqBdm f9ompIpr6ZwyAC7qQfMhNjVuqb1WOBv/XMPpxtBxLjgzCkFkuk8IZ/6raOVN9xHKUxCi +HdDxm5vWbfcdKZviopftvXxXjgUuwykY+mWfJdgmZrO+UVdpWkz9fdf3pKA75Wd3c2/ W5Ng== X-Gm-Message-State: APzg51AmbpD1xi+GSSsTkqpBxBoBWznTAiv3j02utM/ynawJCkGSkwf/ FwN6ztoWEXu9918x2c67H0CQXAaO/U44qJDqnan7Qw== X-Received: by 2002:a6b:9157:: with SMTP id t84-v6mr9972718iod.187.1535374726710; Mon, 27 Aug 2018 05:58:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5e:9402:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 05:58:46 -0700 (PDT) In-Reply-To: <20180827125226.GD13848@rapoport-lnx> References: <20180827082101.5036-1-brgl@bgdev.pl> <20180827082101.5036-2-brgl@bgdev.pl> <20180827103915.GC13848@rapoport-lnx> <20180827125226.GD13848@rapoport-lnx> From: Bartosz Golaszewski Date: Mon, 27 Aug 2018 14:58:46 +0200 Message-ID: Subject: Re: [PATCH 2/2] clk: pmc-atom: use devm_kstrdup_const() To: Mike Rapoport Cc: Michael Turquette , Stephen Boyd , Greg Kroah-Hartman , "Rafael J . Wysocki" , Arend van Spriel , Ulf Hansson , Bjorn Helgaas , Vivek Gautam , Robin Murphy , Joe Perches , Heikki Krogerus , Andrew Morton , Michal Hocko , Al Viro , Jonathan Corbet , Roman Gushchin , Huang Ying , Kees Cook , Bjorn Andersson , linux-clk , Linux Kernel Mailing List , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-08-27 14:52 GMT+02:00 Mike Rapoport : > On Mon, Aug 27, 2018 at 02:28:45PM +0200, Bartosz Golaszewski wrote: >> 2018-08-27 12:39 GMT+02:00 Mike Rapoport : >> > On Mon, Aug 27, 2018 at 10:21:01AM +0200, Bartosz Golaszewski wrote: >> >> Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as >> >> an example of how to use this new routine to shrink driver code. >> >> >> >> While we're at it: replace a call to kcalloc() with devm_kcalloc(). >> >> >> >> Signed-off-by: Bartosz Golaszewski >> >> --- >> >> drivers/clk/x86/clk-pmc-atom.c | 19 ++++--------------- >> >> 1 file changed, 4 insertions(+), 15 deletions(-) >> >> >> >> diff --git a/drivers/clk/x86/clk-pmc-atom.c b/drivers/clk/x86/clk-pmc-atom.c >> >> index 08ef69945ffb..daa2192e6568 100644 >> >> --- a/drivers/clk/x86/clk-pmc-atom.c >> >> +++ b/drivers/clk/x86/clk-pmc-atom.c >> >> @@ -253,14 +253,6 @@ static void plt_clk_unregister_fixed_rate_loop(struct clk_plt_data *data, >> >> plt_clk_unregister_fixed_rate(data->parents[i]); >> >> } >> >> >> >> -static void plt_clk_free_parent_names_loop(const char **parent_names, >> >> - unsigned int i) >> >> -{ >> >> - while (i--) >> >> - kfree_const(parent_names[i]); >> >> - kfree(parent_names); >> >> -} >> >> - >> >> static void plt_clk_unregister_loop(struct clk_plt_data *data, >> >> unsigned int i) >> >> { >> >> @@ -286,8 +278,8 @@ static const char **plt_clk_register_parents(struct platform_device *pdev, >> >> if (!data->parents) >> >> return ERR_PTR(-ENOMEM); >> >> >> >> - parent_names = kcalloc(nparents, sizeof(*parent_names), >> >> - GFP_KERNEL); >> >> + parent_names = devm_kcalloc(&pdev->dev, nparents, >> >> + sizeof(*parent_names), GFP_KERNEL); >> >> if (!parent_names) >> >> return ERR_PTR(-ENOMEM); >> >> >> >> @@ -300,7 +292,8 @@ static const char **plt_clk_register_parents(struct platform_device *pdev, >> >> err = PTR_ERR(data->parents[i]); >> >> goto err_unreg; >> >> } >> >> - parent_names[i] = kstrdup_const(clks[i].name, GFP_KERNEL); >> >> + parent_names[i] = devm_kstrdup_const(&pdev->dev, >> >> + clks[i].name, GFP_KERNEL); >> >> } >> >> >> >> data->nparents = nparents; >> >> @@ -308,7 +301,6 @@ static const char **plt_clk_register_parents(struct platform_device *pdev, >> >> >> >> err_unreg: >> >> plt_clk_unregister_fixed_rate_loop(data, i); >> >> - plt_clk_free_parent_names_loop(parent_names, i); >> > >> > What happens if clks[i].name is not a part of RO data? The devm_kstrdup_const >> > will allocate memory and nothing will ever free it... >> > >> >> I'm looking at it and trying to see if I'm missing something, but >> AFAIK the whole concept of devm_* is to leave out the resource >> management part. >> >> devm_kstrdup_const() will internally call devm_kstrdup() for strings >> that are not in .rodata and once the device is detached, the string >> will be freed (or not if it's in .rodata). > > And when it's going to be freed, how the resource management will know > whether it's .rodata or not? > If the string to be duplicated is in .rodata, it's returned as is from devm_kstrdup_const(). Never gets added to the devres list, never get's freed. When the string to be duplicated is not in .rodata, devm_kstrdup() is called from devm_kstrdup_const(). Now the string is in the devres list of this device and it will get freed on driver detach. I really don't see what else could be a problem here. BR Bart >> BR >> Bart >> >> > And, please don't drop kfree(parent_names) here. >> > >> >> return ERR_PTR(err); >> >> } >> >> >> >> @@ -351,15 +343,12 @@ static int plt_clk_probe(struct platform_device *pdev) >> >> goto err_unreg_clk_plt; >> >> } >> >> >> >> - plt_clk_free_parent_names_loop(parent_names, data->nparents); >> >> - >> >> platform_set_drvdata(pdev, data); >> >> return 0; >> >> >> >> err_unreg_clk_plt: >> >> plt_clk_unregister_loop(data, i); >> >> plt_clk_unregister_parents(data); >> >> - plt_clk_free_parent_names_loop(parent_names, data->nparents); >> > >> > Ditto. >> > >> >> return err; >> >> } >> >> >> >> -- >> >> 2.18.0 >> >> >> > >> > -- >> > Sincerely yours, >> > Mike. >> > >> > > -- > Sincerely yours, > Mike. >