From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id ED5F614EC; Sun, 4 Nov 2018 21:49:40 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8B09B217DD; Sun, 4 Nov 2018 15:49:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 04 Nov 2018 15:49:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=VXTIp1C0K4EfkmIfqOaNQQ10NS8cEVizH1gk/azXSgs=; b=iQXqgGiQZ4VV PmSR/jYjG11FN4h7eJYoJcklVHayybzyGSvKfjBPl7AddBBfokeIO69/XGLqr312 GkE0JLfo2vXY8SLywv4fFKaCAh0JP59pZtWLkuy9RbF4eZH+wVtJRjmsYKNUdJMy hVk26eufuSV0B0HzM++O3gQh7iUgBl8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=VXTIp1C0K4EfkmIfqOaNQQ10NS8cEVizH1gk/azXS gs=; b=aVxPbrZjFnnrv2IiVHC3kFID+7K30f4RCoOYAFgjg3oeIOOYVf23WLTUg p9hjghyyc5uNhBY3p7RT0Gh9/O2Et24fkCxBYV8Tffi7bQ0w2mN9qqP9g5LYvFnb EK1xfDN9dp3IJTVkWWj9JOf1oJpt4h09473Ow7gLi6FbQG9eSXjtJQY9Mb/QuLkE DpUHGeRd3qXQIJ/wT2aHsrjN+4TpN577FARA4BmkgdrLDLIpYERCahVaMGwbReKi +n5hz2M9q2oOLdiq2Chx4u+o10zLKBKZKSlLG7FCUVjRt1Wcn0JIyE1jYzDqJtjh D/DaVcmZcAWs7V9QdJqiQEXN1u83g== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2AAD2E40E6; Sun, 4 Nov 2018 15:49:39 -0500 (EST) From: Thomas Monjalon To: David Hunt Cc: dev@dpdk.org, lei.a.yao@intel.com, stable@dpdk.org Date: Sun, 04 Nov 2018 21:49:37 +0100 Message-ID: <3183438.eAJMS0E4RF@xps> In-Reply-To: <20181031115032.12010-1-david.hunt@intel.com> References: <20181031115032.12010-1-david.hunt@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] examples/vm_power: fix app to respect max cpus 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: Sun, 04 Nov 2018 20:49:41 -0000 31/10/2018 12:50, David Hunt: > 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 + Cc: stable@dpdk.org Applied, thanks