Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5868562imm; Mon, 27 Aug 2018 05:54:19 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZw+lneB5UG6MIAToIellm6bj/zccmQN8TdzL0PVM19Y88/b3sxr0DI2TDZqca17qfHsGB1 X-Received: by 2002:a17:902:5a87:: with SMTP id r7-v6mr12972110pli.247.1535374459784; Mon, 27 Aug 2018 05:54:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535374459; cv=none; d=google.com; s=arc-20160816; b=fAXNZ39xQwd0qLoWkLndh18JOa9q0jiWPgLF4hozImXCPJjKO2GEVrZKg4QIi4Z0fo x7aIZTtr2cuZCtM5NGzf3n8rX733JZfDQwU/0xUGYldVBRIb2XCMIrj9M2P696sfjBIQ KobOAqduWCUubrviKWm8VNAI6ByO0TiQszGIhhA0togYia0nxGbv7ZQr94IfFytCJjh4 fqtcEduNdQmtiFAJ7ukFF/6NFgBWDv9AIossFxReBSqsFZgFAs2BWrKSq4kNxWGIyWh7 CEdiM3Javr+hTikZ52XVLM5w7hjvkiKTaDXCSdwtzQdW2uCAFH5IfRWqfcX2QfqSWPbm SPhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:subject:cc:to:from:date :arc-authentication-results; bh=f6bK4uqaL1spjxo1Y9QERqKEiRQXev32rvAGjpHsrtw=; b=HRWdPb6JsGhzCmXcsut66157A9sB0l51QonCJKKYQY2+Mxa/YNJYelhlP3AT8xLafw Ig7V7Ta37SId2QawiTl8olXiaqeCkJj2SL+Li1X7K2WamMdXp2kbCjSO8XSvLHBYhRi9 PC/pqMbhdSge5aOY1w3Xn0OxYYpoJAtBUG74C8kAI67ew9MSVrnazziQp0B0SQOhyAV+ Em8cVoXBIm46+9hY12BM6HLQt3LMrF2G7cjG3xmmzLOmPUiRme8LB2sBSk9dSpIMlqH9 1qb4OVWbYfTWiuANgqRAHsCbMLVtiYk4TkfXOsugtHHH6aqbP57pfiwkH4impvdEKxKw +qQg== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 190-v6si16932893pfu.343.2018.08.27.05.54.03; Mon, 27 Aug 2018 05:54:19 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727111AbeH0QjO (ORCPT + 99 others); Mon, 27 Aug 2018 12:39:14 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59024 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726851AbeH0QjO (ORCPT ); Mon, 27 Aug 2018 12:39:14 -0400 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7RCcZtS006604 for ; Mon, 27 Aug 2018 08:52:40 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2m4h7413fv-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 27 Aug 2018 08:52:40 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Aug 2018 13:52:38 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 27 Aug 2018 13:52:32 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7RCqVwC33357994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Aug 2018 12:52:31 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A02BEAE058; Mon, 27 Aug 2018 15:52:03 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 19B34AE053; Mon, 27 Aug 2018 15:52:02 +0100 (BST) Received: from rapoport-lnx (unknown [9.148.8.97]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 27 Aug 2018 15:52:02 +0100 (BST) Date: Mon, 27 Aug 2018 15:52:27 +0300 From: Mike Rapoport To: Bartosz Golaszewski 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 Subject: Re: [PATCH 2/2] clk: pmc-atom: use devm_kstrdup_const() References: <20180827082101.5036-1-brgl@bgdev.pl> <20180827082101.5036-2-brgl@bgdev.pl> <20180827103915.GC13848@rapoport-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 18082712-4275-0000-0000-000002B091C3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18082712-4276-0000-0000-000037B9950B Message-Id: <20180827125226.GD13848@rapoport-lnx> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-27_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808270137 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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.