From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2F1271B494 for ; Fri, 23 Nov 2018 11:29:04 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 98BBE4E915; Fri, 23 Nov 2018 10:29:03 +0000 (UTC) Received: from ktraynor.remote.csb (unknown [10.36.118.7]) by smtp.corp.redhat.com (Postfix) with ESMTP id A52F317DA1; Fri, 23 Nov 2018 10:29:02 +0000 (UTC) From: Kevin Traynor To: David Hunt Cc: dpdk stable Date: Fri, 23 Nov 2018 10:26:18 +0000 Message-Id: <20181123102713.17309-14-ktraynor@redhat.com> In-Reply-To: <20181123102713.17309-1-ktraynor@redhat.com> References: <20181123102713.17309-1-ktraynor@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 23 Nov 2018 10:29:03 +0000 (UTC) Subject: [dpdk-stable] patch 'examples/vm_power: respect maximum CPUs' has been queued to stable release 18.08.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 10:29:04 -0000 Hi, FYI, your patch has been queued to stable release 18.08.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 11/29/18. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. If the code is different (ie: not only metadata diffs), due for example to a change in context or macro names, please double check it. Thanks. Kevin Traynor --- >>From f604582776562e7788dcc616e3e884ddd123456b Mon Sep 17 00:00:00 2001 From: David Hunt Date: Wed, 31 Oct 2018 11:50:32 +0000 Subject: [PATCH] examples/vm_power: respect maximum CPUs [ upstream commit c12ade20c27658d488439a55f4b6d88a6f0637bf ] The vm_power_manager app was not respecting the POWER_MGR_MAX_CPUS during initialisation, so if there were more CPUs than this value (64), it would lead to buffer overruns of there were more then 64 cores in the system. Added in a check during init and un-init to only initialise up to lcore_id 63. This raises the question as to why not simply increase the value of POWER_MGR_MAX_CPUS. Well, it's not that simple, as many of the APIs take a uint64_t as a parameter for the core mask, and this will not work for cores greater than 63. So some work needs to be done in the future to remove this limitation. For now we'll fix the memory corruption. Also, the patch that this fixes says "allow greater than 64 cores" but that's not across the entire application, it's only for the out-of-band monitoring. I'll add a notice for an API change in the next release to clean this up, i.e. depricate any API calls that use masks. Fixes: 6453b9284b64 ("examples/vm_power: allow greater than 64 cores") Signed-off-by: David Hunt --- examples/vm_power_manager/power_manager.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/examples/vm_power_manager/power_manager.c b/examples/vm_power_manager/power_manager.c index b7769c3c3..f9e8c0abd 100644 --- a/examples/vm_power_manager/power_manager.c +++ b/examples/vm_power_manager/power_manager.c @@ -96,4 +96,5 @@ power_manager_init(void) int ret = 0; struct core_info *ci; + unsigned int max_core_num; rte_power_set_env(PM_ENV_ACPI_CPUFREQ); @@ -106,5 +107,10 @@ power_manager_init(void) } - for (i = 0; i < ci->core_count; i++) { + if (ci->core_count > POWER_MGR_MAX_CPUS) + max_core_num = POWER_MGR_MAX_CPUS; + else + max_core_num = ci->core_count; + + for (i = 0; i < max_core_num; i++) { if (ci->cd[i].global_enabled_cpus) { if (rte_power_init(i) < 0) @@ -166,4 +172,5 @@ power_manager_exit(void) int ret = 0; struct core_info *ci; + unsigned int max_core_num; ci = get_core_info(); @@ -174,5 +181,10 @@ power_manager_exit(void) } - for (i = 0; i < ci->core_count; i++) { + if (ci->core_count > POWER_MGR_MAX_CPUS) + max_core_num = POWER_MGR_MAX_CPUS; + else + max_core_num = ci->core_count; + + for (i = 0; i < max_core_num; i++) { if (ci->cd[i].global_enabled_cpus) { if (rte_power_exit(i) < 0) { -- 2.19.0 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2018-11-23 10:22:54.609972791 +0000 +++ 0014-examples-vm_power-respect-maximum-CPUs.patch 2018-11-23 10:22:54.000000000 +0000 @@ -1,8 +1,10 @@ -From c12ade20c27658d488439a55f4b6d88a6f0637bf Mon Sep 17 00:00:00 2001 +From f604582776562e7788dcc616e3e884ddd123456b Mon Sep 17 00:00:00 2001 From: David Hunt Date: Wed, 31 Oct 2018 11:50:32 +0000 Subject: [PATCH] examples/vm_power: respect maximum CPUs +[ upstream commit c12ade20c27658d488439a55f4b6d88a6f0637bf ] + The vm_power_manager app was not respecting the POWER_MGR_MAX_CPUS during initialisation, so if there were more CPUs than this value (64), it would lead to buffer overruns of there were more then 64 cores in @@ -23,7 +25,6 @@ clean this up, i.e. depricate any API calls that use masks. Fixes: 6453b9284b64 ("examples/vm_power: allow greater than 64 cores") -Cc: stable@dpdk.org Signed-off-by: David Hunt ---