Received: by 2002:ac8:1418:0:b0:3ab:920c:4c8b with SMTP id k24csp1063639qtj; Fri, 20 Jan 2023 06:22:50 -0800 (PST) X-Google-Smtp-Source: AMrXdXvlz7jANox82m1X8LQ2u/rAmH9MW0huKK0b83mvplb/siojFAiCW5vnaZT37EPN5MPq5w76 X-Received: by 2002:aa7:8bd6:0:b0:588:e132:a2f8 with SMTP id s22-20020aa78bd6000000b00588e132a2f8mr14657410pfd.23.1674224570476; Fri, 20 Jan 2023 06:22:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674224570; cv=none; d=google.com; s=arc-20160816; b=OPaYDgYzO4MCi/mOqVoGEvpxK+DpW+hXjQgu5kJMIIwpAzEnMzS4uJzWj1Y8DZAoau kLlzDaQmlNaG8u6cBqTLcOVz6AVLFUFQGjlQQvzzD1r2FNrZENWzv0QIxs3VPTYsi/4r e46j8xlY55sevbSZQ79UgYvP20fXf2JglCGqxpbv/RyscbtLSPsK8rt6qEvVhhX9WgjI io5dR8HmtRkvG5seUCTapJkNiGx5eHsONCrCjWFu+eHeusqafQp5X1OK4Pd+Cs+J7dND pKAKfjwpcZiwpH5URZFtn7cySYjmplG7dBQ1uGRhQSAEzlpgPEEilpH6Qj+WiDhnJb+L 1Clw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=ugActICuqABJPgs2DMA844zVQO+yJ6DzsC4UoZ9cvY0=; b=GJVFkkbgyDMH3UZlbNl9BXX/K6vjk8nxEIr0fIMgzFUS7Nl2OpT4b6Th0GCrTWyaKW 43bnp+1HSW7lwagNj/Oc70xs5mLJaOgnKws+8giwpld2aL5NQWdGoVtFyENLYswda+j0 A+xidOb2OEv5Wh4M5U/9vkzv36EaH1V8bv24zd3THd/FEkV5cU2CgWwSutlEU89linWC aOPUyaLmsVDQaVny0vo019v3zB97yYPISTf9y4rgUsHQzcjF9Lstz8iaIZN+emzW+2u3 Y4v9hw44eeYPrLWnFRQsFsj91vl5nFuN8uq5mZodi7n/KxleaUC9UWr7ys21WRQfxP5X c3+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w192-20020a627bc9000000b0058a4a6b6cbbsi29342275pfc.126.2023.01.20.06.22.43; Fri, 20 Jan 2023 06:22:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229897AbjATNoM (ORCPT + 50 others); Fri, 20 Jan 2023 08:44:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbjATNoL (ORCPT ); Fri, 20 Jan 2023 08:44:11 -0500 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C4EF6CCF2; Fri, 20 Jan 2023 05:44:10 -0800 (PST) Received: by mail-ej1-f46.google.com with SMTP id ss4so13992138ejb.11; Fri, 20 Jan 2023 05:44:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ugActICuqABJPgs2DMA844zVQO+yJ6DzsC4UoZ9cvY0=; b=I1dRWk2jcx8D1Tl0BycBI0OLyx29efSHBWwdelliCYbzz50CfLJH77Yclgh2uWAZwq 2MLs2+KC2oSG0elq5Wx6d8+YKOCSvJWXy+i97oWqCtEs9rTcehXaeW639ie4iIvBZ3ek FEcnYlcuqCKkh/GmVNAFHlDT9MlEH285HxwdQ8ZJPh2Toay8KXZeM7X0Z1L/3dhbQrNF y75iFlDZ1PYBmdN06GTr0A+QjocylHCmoDg91SWdgjfHmFE4c1Eer2GFLlEOqbmFgfgP SPJhnbnkW4/jq9dYDXaeqyFGbMrbANQfvHIyZAw8ETgI+GWj8hb9tpdDpoDLZL0HF/Fa nvHg== X-Gm-Message-State: AFqh2kqCrRMx4HO+WARodcQGAuf7cu33Q6ePicKXNM2ljOVYpQQaH4t2 TGsm2d9L1UTn3uyBNEGHqpbZKv/ay30SIv4LKVlfV6YF X-Received: by 2002:a17:906:940c:b0:86f:d628:e184 with SMTP id q12-20020a170906940c00b0086fd628e184mr1810820ejx.96.1674222249153; Fri, 20 Jan 2023 05:44:09 -0800 (PST) MIME-Version: 1.0 References: <20221230075159.1482626-1-linmq006@gmail.com> In-Reply-To: <20221230075159.1482626-1-linmq006@gmail.com> From: "Rafael J. Wysocki" Date: Fri, 20 Jan 2023 14:43:57 +0100 Message-ID: Subject: Re: [PATCH] powercap/dtpm_cpu: Fix refcount leak in __dtpm_cpu_setup To: Miaoqian Lin Cc: Daniel Lezcano , "Rafael J. Wysocki" , Lukasz Luba , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 30, 2022 at 8:52 AM Miaoqian Lin wrote: > > The policy return by cpufreq_cpu_get() should be released with > cpufreq_cpu_put() to balance the reference counter. > Add missing cpufreq_cpu_put() to fix this. > > Fixes: 0e8f68d7f048 ("powercap/drivers/dtpm: Add CPU energy model based support") > Signed-off-by: Miaoqian Lin > --- > drivers/powercap/dtpm_cpu.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/drivers/powercap/dtpm_cpu.c b/drivers/powercap/dtpm_cpu.c > index 2ff7717530bf..3083c6b45c90 100644 > --- a/drivers/powercap/dtpm_cpu.c > +++ b/drivers/powercap/dtpm_cpu.c > @@ -195,12 +195,16 @@ static int __dtpm_cpu_setup(int cpu, struct dtpm *parent) > return 0; > > pd = em_cpu_get(cpu); > - if (!pd || em_is_artificial(pd)) > - return -EINVAL; > + if (!pd || em_is_artificial(pd)) { > + ret = -EINVAL; > + goto out_put_policy; > + } > > dtpm_cpu = kzalloc(sizeof(*dtpm_cpu), GFP_KERNEL); > - if (!dtpm_cpu) > - return -ENOMEM; > + if (!dtpm_cpu) { > + ret = -ENOMEM; > + goto out_put_policy; > + } > > dtpm_init(&dtpm_cpu->dtpm, &dtpm_ops); > dtpm_cpu->cpu = cpu; > @@ -220,6 +224,8 @@ static int __dtpm_cpu_setup(int cpu, struct dtpm *parent) > if (ret) > goto out_dtpm_unregister; The part of the patch above is valid, but I don't think that the policy reference counter can be dropped below, because that may allow the policy to go away and this driver will be still using it, won't it? > > + cpufreq_cpu_put(policy); > + > return 0; > > out_dtpm_unregister: > @@ -230,7 +236,8 @@ static int __dtpm_cpu_setup(int cpu, struct dtpm *parent) > for_each_cpu(cpu, policy->related_cpus) > per_cpu(dtpm_per_cpu, cpu) = NULL; > kfree(dtpm_cpu); > - > +out_put_policy: > + cpufreq_cpu_put(policy); > return ret; > } > > -- > 2.25.1 >