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 76E81A04FA; Sun, 2 Feb 2020 15:41:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 76E041BFCC; Sun, 2 Feb 2020 15:41:57 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id EF16C1BFC5 for ; Sun, 2 Feb 2020 15:41:55 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2020 06:41:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,394,1574150400"; d="scan'208";a="253814057" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 02 Feb 2020 06:41:53 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 2 Feb 2020 06:41:53 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 2 Feb 2020 06:41:53 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 2 Feb 2020 06:41:53 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xxm1me/x2gjsL7d3QeQka++4J9syO3+sRbtAsnTMucvDG1M5Q+pp9rOA2dVg55GTbDbDx8LUvxs7zxzH5l2cuhgHLbrJ9Y4yIpAQuv8ZiUuu+umdSznl7BwQTNOnnPRXqFgpFJ4ZuEJcAtuxXEEXtcx3Cr8YSUdyohKFdgWxhRN9GKYklZ3YRTc/O+yhnRxK4N1TGa+uNhUerBfM9ZJ29GR0HCGZB7grjoPSpwy3G2fmTCO+shobLj32YtIt7A7XQUZ9mz6NC79/PlxhQ9iQrlTEET8YBEtvSl5X1q/wq6BPEa3jknOjtu6rqnDXf+adp3IVdPL7l0IrHOopHWsmTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2aWGVj1JwD5mJLxShYPWZqXUWduYWIklTgg+RNKiK/M=; b=EbChCO9r0MmMer3hyy97b/pKWngBPUXWxmmFYg1NckA1fFwXU7IcSsWiBFOHE8kyAA0Z2xm62w3hokcUvdh6pZh9cGEkXR8pJQSH5o3hqlyVNm24Lx8k3jEEYUP/adlNRV2p0wcKCX5j3+RcdLzmWHmalSCxzbKIlLiPjHVyMoW1sw+wvUoLqQapI61Oh2kSv6PAXtLkE8P3XeO53p0EBt2OxRk87nXGrJA+T8x3Llwke6KUrcOFx5a3EfQDrQvJYAscuajOINzDFyie//hAnQBoM6I+ptwZZd0jbeko2OGH/OyBhjKxn6BrofRiQaZccSOMH6a5K6SP/WpqSmaijw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2aWGVj1JwD5mJLxShYPWZqXUWduYWIklTgg+RNKiK/M=; b=HqFKlfVDbzuKmfsoinE4rDG1ox+11MaOf12CjQFN+83FyARrZg6gAH1qGt8rulU79DSoVXqfhSN20BHQ6GnFPnaIPt8laUyap+jAyicteD6noCCM0U/Z8v3lrzIT6Rv4grfZpaOZNK+fVbG66jNBD3/uttqfV5ZbprhbuooV3G0= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by SN6PR11MB3504.namprd11.prod.outlook.com (52.135.125.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.33; Sun, 2 Feb 2020 14:41:51 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::395e:eb75:6ab7:2ba5]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::395e:eb75:6ab7:2ba5%3]) with mapi id 15.20.2686.031; Sun, 2 Feb 2020 14:41:50 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , 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" Thread-Topic: [dpdk-dev] [PATCH v2 4/4] add ABI checks Thread-Index: AQHV1smFFsBCT8/Ts0WE6L1M7kr0nKgB6XuAgAAHoQCAAB+HAIAAAt+AgAFOQgCAAEVxAIABLWUAgAMQ1QCAABnuoA== Date: Sun, 2 Feb 2020 14:41:49 +0000 Message-ID: References: <20191220152058.10739-1-david.marchand@redhat.com> <6121442.K2JlShyGXD@xps> <1779027.taCxCBeP46@xps> In-Reply-To: <1779027.taCxCBeP46@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWI1NjU0ODMtNTgxYy00OWEwLWI1NWMtYTkxMTllOGVlNTk0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidTQwUEJXbWV3VFlTVHhsSmpMZ3NZVXBZdHVSWUtVMjVGVjNjUjVVRWhLZFljdXZ1Uko3Q1hMYTNEcWZpZXVXTCJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e8f29e99-7c37-475c-4be4-08d7a7ee09ce x-ms-traffictypediagnostic: SN6PR11MB3504: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(366004)(136003)(199004)(189003)(33656002)(8676002)(55016002)(71200400001)(478600001)(86362001)(81166006)(8936002)(2906002)(81156014)(9686003)(6636002)(4326008)(52536014)(7696005)(66556008)(66946007)(66446008)(66476007)(64756008)(316002)(76116006)(5660300002)(54906003)(110136005)(53546011)(186003)(6506007)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB3504; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xrYxlsKNMckCps2+9N6hmhaEfVBqa8iNdDdc/JmDdqD75TQS7U7eOGIaAG+HzxcftCf3lg1WxAKXBDnSuxqSSVfX7cbecDGjNELLsFSX1uN6wfL5UWvZkGVAXay9KWcInWFm5P4ecHywYZ5RGinGM5fKJlc7Aed08xOqzz29fYaLqrZmOz5DUYTc90LEIBDtGTWVy6lHd3DQBLEQQQTass0AV5CovGsYayN5EYF6LMbehXfDH0Mu6Am9OgozvnEmYeP2t+SXfdCMZrrlCMgeMJBbqjrOcYR6pdocCOSynOC1wfD+t05r+qyO1phj1AL513Jcwh2OXcB94PWtQ/ncwfYiDJpmdEJY/y2+AB8kr0PqBpf5rheGEFX+FJWX49TZGuiSnMLKRrPewURawc8qJtz11se4MvfX2FoO57Q08em3oEHwwwxOnb6s87G9DseC x-ms-exchange-antispam-messagedata: NMgH+E3PPYknPAyXxixqIqrSqIZtlFNlRYKvluU8HYz62BH8n+mbCKTydDbeYo7BhfnS5U6u+1dqWy8ddp6pMUHKYq8MRyGRX4T+KQM7AxRcIiMu4L+2DBrO9PJy+fM+rLZMBmlfqLLqJZUk1ktKtA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e8f29e99-7c37-475c-4be4-08d7a7ee09ce X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2020 14:41:49.9957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ev9MGPeRJGsnvyO6MpY9JGp06KP27hlPmxQl4iqfERm6+nWxsVuCkQxShyaVbxSjt4nR952NVn5TkJgpvj+HVYLWEvisClVMAKkqCoLOzNU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3504 X-OriginatorOrg: intel.com 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 whic= h is experimental. > > > > > > > > Independent from being experiment and not, this shouldn't be a prob= lem, 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 different= ly 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 wi= th old DPDK, > > > > it will know only up to '6', 7 and more means invalid to the applic= ation. So it > > > > won't send these values also it should ignore these values from lib= rary. 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 pr= oblem. > > But for the same issue with sym crypto below, I believe Ferruh's explan= ation 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 sti= ll using the old value > > which will be within bounds. If it's picking up the higher new value fr= om the lib it must > > have been compiled against the lib so shouldn't have problems. >=20 > 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. >=20 > > 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. >=20 > Let me demonstrate where the API may "use" the new value > RTE_CRYPTO_AEAD_CHACHA20_POLY1305 and how it impacts the application. >=20 > 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 =3D 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 =3D 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 (=3D 3). > The application uses this value: > ++ aead_dev_count[info.capabilities.sym.aead.algo]; > The application is crashing because of out of bound access. I'd say this is an example of bad written app. It probably should check that returned by library value doesn't exceed its internal array size.=20 Konstantin