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 CA44FA046B for ; Tue, 23 Jul 2019 15:39:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AC5D51C02E; Tue, 23 Jul 2019 15:39:13 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 4AA011BFFB; Tue, 23 Jul 2019 15:39:10 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 24961609; Tue, 23 Jul 2019 09:39:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 23 Jul 2019 09:39:09 -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=eZYhiWjpoeAA5WoqPiUaOpbLO2bzqs/0+ulrYMLU4IE=; b=IBvYU34Gh6iX WW0nfmt3fnGJdNmK85rtYiYmFB2xUUHZQlLwCv1pnAABuQurAWQtThlE0gNPKHtF mqpDvQcLdOAKsRlevsPr/Ex9Jvmurb4irXYAqokzi92dkvqRl65RCieOo5hEvqqy pH1UwHS5Q7bgqG1HHyXJumXzQZzCtPk= 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=eZYhiWjpoeAA5WoqPiUaOpbLO2bzqs/0+ulrYMLU4 IE=; b=IQiGW+aeYmUBjjcdqhDM9HCiDIR/nwg8coGrsGtrKO4Pi3jdKivpW/P8J oUjco1GRzs6mQ87LHPQrsaw+ZcVsUC471E/9YGhoKUz6KJWbvV/OXmrLjVXzLX1n oIbF//Ncej3aM02Y5C6xoEyJ3AZd8H8osWHtxMaGQEuL5tPM6qdciQpQH2tZtwLo PXugFqhY3ozZNmq63nB3Cxr5CJ/IK19ihvscnR3SC55eL4e5gzaw9pxavX3b4EK2 c3ApaAIG/2tpcrFtDDag/GeTF0DEUKip+CiqSjUILqtCUutihUZAbX/Zz5uv0x4N mj/OLVVcaR/vxQDDPfSVMnyve8pag== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrjeekgdeijecutefuodetggdotefrodftvf 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 AFDAE80062; Tue, 23 Jul 2019 09:39:07 -0400 (EDT) From: Thomas Monjalon To: Andrew Rybchenko Cc: dev@dpdk.org, Ferruh Yigit , stable@dpdk.org Date: Tue, 23 Jul 2019 15:39:06 +0200 Message-ID: <1746857.eD02m7bUWG@xps> In-Reply-To: References: <1563873208-5096-1-git-send-email-arybchenko@solarflare.com> <1925153.tuYcfiiuYR@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case 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: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 23/07/2019 15:34, Andrew Rybchenko: > On 7/23/19 4:14 PM, Thomas Monjalon wrote: > > 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. > > I've not thought about such ways to check. I would expected check > for not NULL device or driver_name. It is not defined behaviour of > the function to not touch dev_info in the case of bad port ID. > > > Why is it urgent to have this workaround? > > Nothing really urgent, but I still think that it is a right fix to be > applied and backported to stable branches. > I really met calls with invalid port ID and it took some time > to understand where uninitialized data come from. > > > Can we wait one more release for the definitive fix with error code? > > No strong opinion, but definitive fix will not be backported. You're right. Acked-by: Thomas Monjalon