From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 28EB0A046B for ; Tue, 23 Jul 2019 15:14:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8B2701C024; Tue, 23 Jul 2019 15:14:43 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id CCD201C000; Tue, 23 Jul 2019 15:14:41 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AE5D35E7; Tue, 23 Jul 2019 09:14:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 23 Jul 2019 09:14:41 -0400 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=U98ccyV6nfPbqQDOtM8GKa9cLtkkRDqsZuBfi7aMxAA=; b=TBgjDuGv3wmg 5bHmsk0xSimjpO9jwC2whPNF1QHukSCDBP16hGYZJ5PDiaZUeV2hw+K070q55HG0 b+Mq6LPmCiIOdQfDo2iUaGwbVfWaU/LzCEj4bOnZfEVDkgbWmcigd5902oZRHMr4 juYC9zmP8kWN4m7g5xL37JnrIFyYGaI= 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=fm3; bh=U98ccyV6nfPbqQDOtM8GKa9cLtkkRDqsZuBfi7aMx AA=; b=RGGy6oifqXFuaXVE/Pl9u+/PNhH1nL8uqOfpmsa81pxBYzoU5Vp9NwNNn 9jL2QEyLBFZ0w67yQ182aernRWVJ6y+SE+UZg8O7c5Ti9oeyKJ4tsvZO7E8cp9Hu UHpRv2xTK6W/VX6sqADImFNEeqcY7SUafGP86hZo7igZnmSS8zPa3ZKZ3Dct+w22 aMZBB2sd20QAF/bMvg+C649NU/ixuXdgcMEOBPVxrbbpxCUlLR6U7xUIDBE10Zva /ThwfG8Y2qq1lROpS2HziuPJsXMjNMyUTPDt/0rtWlIuCLZ2hmlvYNA5WEtzJv2Y BZZUsVRVdHFjVb5DXpxQONo3KNvPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrjeekgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 4B5C4380075; Tue, 23 Jul 2019 09:14:39 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: dev@dpdk.org, Ferruh Yigit , stable@dpdk.org Date: Tue, 23 Jul 2019 15:14:35 +0200 Message-ID: <1925153.tuYcfiiuYR@xps> In-Reply-To: <1563883881-16258-1-git-send-email-arybchenko@solarflare.com> References: <1563873208-5096-1-git-send-email-arybchenko@solarflare.com> <1563883881-16258-1-git-send-email-arybchenko@solarflare.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 23/07/2019 14:11, Andrew Rybchenko: > rte_eth_dev_info_get() returns void and caller does know if the function > does its job or not. Changing of the return value to int would be > API/ABI breakage which requires deprecation process and cannot be > backported to stable branches. For now, make sure that device info is > initialized even in the case of invalid port ID. > > Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling") > Cc: stable@dpdk.org > > Signed-off-by: Andrew Rybchenko > --- > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > + /* > + * Init dev_info before port_id check since caller does not have > + * return status and does not know if get is successful or not. > + */ > + memset(dev_info, 0, sizeof(struct rte_eth_dev_info)); If someone was using a canary to detect failure, it will be resetted. Why is it urgent to have this workaround? Can we wait one more release for the definitive fix with error code? > + > RTE_ETH_VALID_PORTID_OR_RET(port_id); > dev = &rte_eth_devices[port_id]; > > - memset(dev_info, 0, sizeof(struct rte_eth_dev_info)); > dev_info->rx_desc_lim = lim; > dev_info->tx_desc_lim = lim; > dev_info->device = dev->device;