From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 34B821B44C; Thu, 31 Jan 2019 16:04:29 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6BAE82108A; Thu, 31 Jan 2019 10:04:27 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 31 Jan 2019 10:04:27 -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=GZobxzm8D4zaqRLjyPdBCDtO2KS4q4DifZKACfsnYc4=; b=ik2d8COovh3S cw5gTobr7C0oE5IQTyUvxQvze3xQtQRJOUSsWnRZi4IZWRELqN/sme2ui6N4mIxm asGYNdtYJtCr3lRotOuW/vRk47Dt7MFMlCBER1Tix609DO6YeuUMCJWRxeoLXLAY HR4cwqD9xQtDmRJxBapWoU1K+ymgRF8= 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=GZobxzm8D4zaqRLjyPdBCDtO2KS4q4DifZKACfsnY c4=; b=WKwLl+cdQ0RsCNiek//XGG8qiifP1bQsonLlX7k1SMLxrt9mA/os6MHzQ tFo60fR6WFdhAuu6W8lku+En9ZcKd5/Jm857zuqkkG86+ubtnVMlPmmahoWfXz1L He63X/2+je1rpFAJJXVGbp8u0/uC8DCtlclmjSAOQgb/L3/cTkIPwEWZcpUOv1es r5Wuo8ivnZToywU1JKkKtbtPp+5Xm56jn1T2l1qBHOx7wh7bqoas4rOtJwV9rwn2 LTAxTWhKKE+lEnbcNLxe+qwOGPxvwL0y1xau9mPx8wQCR9K+I5WcIvwGilg4GKBu DaFQElmkYlKV+88CnBo6cPFi6QzCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrjeeigdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfh gggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceo thhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvddtfe drudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 43A7B10316; Thu, 31 Jan 2019 10:04:25 -0500 (EST) From: Thomas Monjalon To: Kevin Traynor Cc: "Burakov, Anatoly" , dev@dpdk.org, Bruce Richardson , ferruh.yigit@intel.com, andy01011501@163.com, Yongseok Koh , "stable@dpdk.org" Date: Thu, 31 Jan 2019 16:04:23 +0100 Message-ID: <1614490.ZEn2XMpOzn@xps> In-Reply-To: References: <4e041e83fb00d8d818682997f795928c36b3283a.1547127516.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 15:04:29 -0000 31/01/2019 15:15, Kevin Traynor: > On 01/31/2019 02:10 PM, Burakov, Anatoly wrote: > > On 31-Jan-19 11:21 AM, Kevin Traynor wrote: > >> On 01/10/2019 01:38 PM, Anatoly Burakov wrote: > >>> Currently, we use strdup in a few places to store command-line > >>> parameter values for certain internal config values. There are > >>> several issues with that. > >>> > >>> First of all, they're never freed, so memory ends up leaking > >>> either after EAL exit, or when these command-line options are > >>> supplied multiple times. > >>> > >>> Second of all, they're defined as `const char *`, so they > >>> *cannot* be freed even if we wanted to. > >>> > >>> Finally, strdup may return NULL, which will be stored in the > >>> config. For most fields, NULL is a valid value, but for the > >>> default prefix, the value is always expected to be valid. > >>> > >>> To fix all of this, three things are done. First, we change > >>> the definitions of these values to `char *` as opposed to > >>> `const char *`. This does not break the ABI, and previous > >>> code assumes constness (which is more restrictive), so it's > >>> safe to do so. > >>> > >>> Then, fix all usages of strdup to check return value, and add > >>> a cleanup function that will free the memory occupied by > >>> these strings, as well as freeing them before assigning a new > >>> value to prevent leaks when parameter is specified multiple > >>> times. > >>> > >>> And finally, add an internal API to query hugefile prefix, so > >>> that, absent of a valid value, a default value will be > >>> returned, and also fix up all usages of hugefile prefix to > >>> use this API instead of accessing hugefile prefix directly. > >>> > >>> Bugzilla ID: 108 > >>> > >> > >> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla > >> was reported on 17.11. Is it for backport to stable branches? > >> > > > > It can be. Whether it's worth the effort of backporting is not my call :) > > > > It's fine for 18.11 branch anyway, just needed a little help due to some > changed context. I will send diff to stable list as normal. Nothing was broken. I see it like an improvement. Not sure it is worth the effort.