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 78EA1A04FA; Sun, 2 Feb 2020 14:06:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B72DB1BFDF; Sun, 2 Feb 2020 14:06:05 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id DB00D1BFCC for ; Sun, 2 Feb 2020 14:06:03 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id F3286315E; Sun, 2 Feb 2020 08:06:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 02 Feb 2020 08:06:03 -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=5aWcw59Z63NtLzjqU9bhBuh6q6EDujeoz4KyocOQHNw=; b=HSo10e5dKtLE CDOy2tOy3OKl1gpZhae2/Gehw7jakd2Z9GJ5//1YkPhD6RzBTv0rTUB0vjbH0UBl 9d1FBhpr6s++ndCtSD0FSG2NP5xVK8qC6bNlELq1gv/r5xDavhIB94EgNYoXKB3N OsITv8twlhdEj6FnXWoJ2EBPsgGaeno= 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=5aWcw59Z63NtLzjqU9bhBuh6q6EDujeoz4KyocOQH Nw=; b=bsos2hhu4iaooSzzTXQLcHaHHcLsZ6PaiwYc7VC0uSitUidupzHHMB0cm XRIPJIE3WzTmKNqb8ZhiOJOxuAsr009Nq1g+fXCbu6wc5y7vVAKytQcKc+2PPu+i Gfv8x8ZWoQFpBcJ6Gp6KrCWfm+gH0E11/yomFJKrqs8utEbEkRDbgk9cpRg2tQK0 ls525r0Ug+/d4qEgh5ryz7OhxZtctn6eoputPrWqTpc18Kn+PM8LzcCvWWuXhcJp KPUfArlsfbeWOIy15anJEf5QpGUETbmLVTV7J202fTKglb7faOe1au4CWziBbzoI ASdfgfJyWZz6LFKsgtWJiDxL7LCVA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgeehgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epkedurddukeehrddujedtrdduvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (126.170.185.81.rev.sfr.net [81.185.170.126]) by mail.messagingengine.com (Postfix) with ESMTPA id 74605328005A; Sun, 2 Feb 2020 08:05:58 -0500 (EST) From: Thomas Monjalon To: Akhil Goyal , "Yigit, Ferruh" , "Trahe, Fiona" Cc: David Marchand , Anoob Joseph , "Kusztal, ArkadiuszX" , "dev@dpdk.org" , "Richardson, Bruce" , "nhorman@tuxdriver.com" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "Trahe, Fiona" , aconole@redhat.com Date: Sun, 02 Feb 2020 14:05:56 +0100 Message-ID: <1779027.taCxCBeP46@xps> In-Reply-To: References: <20191220152058.10739-1-david.marchand@redhat.com> <6121442.K2JlShyGXD@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks 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" 31/01/2020 15:16, Trahe, Fiona: > On 1/30/2020 8:18 PM, Thomas Monjalon wrote: > > 30/01/2020 17:09, Ferruh Yigit: > > > On 1/29/2020 8:13 PM, Akhil Goyal wrote: > > > > > > > > I believe these enums will be used only in case of ASYM case which is experimental. > > > > > > Independent from being experiment and not, this shouldn't be a problem, I think > > > this is a false positive. > > > > > > The ABI break can happen when a struct has been shared between the application > > > and the library (DPDK) and the layout of that memory know differently by > > > application and the library. > > > > > > Here in all cases, there is no layout/size change. > > > > > > As to the value changes of the enums, since application compiled with old DPDK, > > > it will know only up to '6', 7 and more means invalid to the application. So it > > > won't send these values also it should ignore these values from library. Only > > > consequence is old application won't able to use new features those new enums > > > provide but that is expected/normal. > > > > If library give higher value than expected by the application, > > if the application uses this value as array index, > > there can be an access out of bounds. > > [Fiona] All asymmetric APIs are experimental so above shouldn't be a problem. > But for the same issue with sym crypto below, I believe Ferruh's explanation makes > sense and I don't see how there can be an API breakage. > So if an application hasn't compiled against the new lib it will be still using the old value > which will be within bounds. If it's picking up the higher new value from the lib it must > have been compiled against the lib so shouldn't have problems. You say there is no ABI issue because the application will be re-compiled for the updated library. Indeed, compilation fixes compatibility issues. But this is not relevant for ABI compatibility. ABI compatibility means we can upgrade the library without recompiling the application and it must work. You think it is a false positive because you assume the application "picks" the new value. I think you miss the case where the new value is returned by a function in the upgraded library. > There are also no structs on the API which contain arrays using this > for sizing, so I don't see an opportunity for an appl to have a > mismatch in memory addresses. Let me demonstrate where the API may "use" the new value RTE_CRYPTO_AEAD_CHACHA20_POLY1305 and how it impacts the application. Once upon a time a DPDK application counting the number of devices supporting each AEAD algo (in order to find the best supported algo). It is done in an array indexed by algo id: int aead_dev_count[RTE_CRYPTO_AEAD_LIST_END]; The application is compiled with DPDK 19.11, where RTE_CRYPTO_AEAD_LIST_END = 3. So the size of the application array aead_dev_count is 3. This binary is run with DPDK 20.02, where RTE_CRYPTO_AEAD_CHACHA20_POLY1305 = 3. When calling rte_cryptodev_info_get() on a device QAT_GEN3, rte_cryptodev_info.capabilities.sym.aead.algo is set to RTE_CRYPTO_AEAD_CHACHA20_POLY1305 (= 3). The application uses this value: ++ aead_dev_count[info.capabilities.sym.aead.algo]; The application is crashing because of out of bound access.