From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A00614C91 for ; Mon, 14 Jan 2019 15:18:32 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3FD6B2C3B6; Mon, 14 Jan 2019 09:18:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 14 Jan 2019 09:18:32 -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=+vBsBys7EXm48oKGngRXankb5Rve7NZyGsNVpKI9Xv0=; b=mt3q+hEfJU9d MZgjiDnSUZMqa+jrvVpWXSdMPKt3T433bH6178+Yv54QR50nkO5e8pYA21GEtKOj DP8pem/CSbrwbsARTVO8Ft9ffuTDo00075CEqk+1asstC5eHuDYm9POLXzjoDJT8 FtDx/lsvZCg05/jgTTlw4evm2Y7I2TU= 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=+vBsBys7EXm48oKGngRXankb5Rve7NZyGsNVpKI9X v0=; b=RtWL5jW0hYcOkiZddlkUdkwnm2kB+7PhwDjcVJHpxpR+xflLEj8qsP4/V aFD7SvmY7kEy+UkhDpvQUoCgDEj0Z7cfg2+bsTbP3qHe5BW0lyyZCBNZfWxNSIYj jHVSGadvD2SvrNjX8MNMhGWIBBjtvzz2P7riD5dsWRz+PdCzxCJm2BNVV63alEq3 LsrXtTK0R4es7tquLIBnI/CaM8scUe2iXWb4F2cMLEmc+q3thSnCOmquvpIEIkSf /N5MeIOz4ZCExoUyZT0O2MT4mWFAuwYsIIvVzaLUYT0gZtZDe+3bKEpxNcqkM04w OMQOgt+z2HnvCjwucGiL+ZwZhI9XA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgedugdeifecutefuodetggdotefrodftvf 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 B1E6EE4741; Mon, 14 Jan 2019 09:18:30 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, Bruce Richardson , ferruh.yigit@intel.com, andy01011501@163.com Date: Mon, 14 Jan 2019 15:18:29 +0100 Message-ID: <3667118.sJRdelqhzi@xps> In-Reply-To: <4e041e83fb00d8d818682997f795928c36b3283a.1547127516.git.anatoly.burakov@intel.com> 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: Mon, 14 Jan 2019 14:18:32 -0000 10/01/2019 14:38, Anatoly Burakov: > 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 > > Signed-off-by: Anatoly Burakov Applied, thanks