From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 443CBA0548; Fri, 2 Apr 2021 11:26:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C2652140EB8; Fri, 2 Apr 2021 11:26:50 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 973D540141 for ; Fri, 2 Apr 2021 11:26:48 +0200 (CEST) IronPort-SDR: 7zlCfJijOljuDHfJh6gRr6gsJ6+UiKhyEJUaWVUk2w8OuIYnuV99nSM+JbvxM9Gt6zcA3hTsjk KxMmHdmnVVfA== X-IronPort-AV: E=McAfee;i="6000,8403,9941"; a="192536541" X-IronPort-AV: E=Sophos;i="5.81,299,1610438400"; d="scan'208";a="192536541" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2021 02:26:47 -0700 IronPort-SDR: XaI4TI7xWGzPJvjbJhzWo2Fttwe4PgA4/ehTz63BbKc+tp9dKFSgi6gK6ocNBO27NlM98Atb3U IW6FqftMoUQw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,299,1610438400"; d="scan'208";a="394900911" Received: from silpixa00399498.ir.intel.com (HELO silpixa00399498.ger.corp.intel.com) ([10.237.222.97]) by orsmga002.jf.intel.com with ESMTP; 02 Apr 2021 02:26:46 -0700 From: Anatoly Burakov To: dev@dpdk.org Cc: david.hunt@intel.com Date: Fri, 2 Apr 2021 09:26:44 +0000 Message-Id: <20210402092645.258257-1-anatoly.burakov@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210401150614.234257-1-anatoly.burakov@intel.com> References: <20210401150614.234257-1-anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v4 1/2] power: fix pstate base frequency handling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Previous fix for base frequency handling in pstate mode introduced a couple of issues: - When base_frequency file does not exist, it simply bails out because of what appears to be accidental addition of FOPEN_OR_ERR_RET. This is incorrect, as absence of this file is not fatal and is in fact expected on kernel versions earlier than 5.3 - When base_frequency file does exist, it gets opened, but never gets closed, resulting in a resource leak Both issues also manifest themselves as Coverity defects (dead code, and a resource leak), so this fix addresses both. Fixes: 4db9587bbf72 ("power: check sysfs base frequency") Cc: david.hunt@intel.com Coverity issue: 369693 Coverity issue: 369694 Bugzilla ID: 668 Signed-off-by: Anatoly Burakov --- lib/librte_power/power_pstate_cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_power/power_pstate_cpufreq.c b/lib/librte_power/power_pstate_cpufreq.c index 8a1fffaed5..c4639e4b8a 100644 --- a/lib/librte_power/power_pstate_cpufreq.c +++ b/lib/librte_power/power_pstate_cpufreq.c @@ -206,7 +206,6 @@ power_init_for_setting_freq(struct pstate_power_info *pi) pi->lcore_id); f_base = fopen(fullpath_base, "r"); - FOPEN_OR_ERR_RET(f_base, -1); if (f_base == NULL) { /* No sysfs base_frequency, that's OK, continue without */ base_ratio = 0; @@ -221,6 +220,7 @@ power_init_for_setting_freq(struct pstate_power_info *pi) base_ratio = strtoul(buf_base, NULL, POWER_CONVERT_TO_DECIMAL) / BUS_FREQ; + fclose(f_base); } /* Add MSR read to detect turbo status */ -- 2.25.1