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 D8DF7A2EFC for ; Tue, 15 Oct 2019 15:44:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D354E1EBDC; Tue, 15 Oct 2019 15:44:30 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130089.outbound.protection.outlook.com [40.107.13.89]) by dpdk.org (Postfix) with ESMTP id C7FB61EBD5; Tue, 15 Oct 2019 15:44:29 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cOy6bQYHmG0IE7kXj7EimkzCdaBx48EGMqTWt/mwsal4M5EcC8gxP0Ev4YECFdPFMmTUbl8GqE80bzSXTgzlX3BrgrU6sNCW0nk15V5PNs0eIcKQSgQuOJI4StgzhhJZYnMVTRFsCgqCUQkQx+fQ1bgsZlkCdKRkOW2cP9nDCk9RRS4S6nrbrCte3FEDCv/nVVk7kBbEwHzN8EeqlfyamUkVq1e+0FFS50okidqYg2JJrdGTz/3DomJD1Sxl4OlNObJyniadtcszLa/NjnOJW9Cq/WupEd83LuMLao4sm6Ej7MYGVMdfBTMu2OvjSqg/4kCX+w63Keyn/8wNXJkSdA== 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=+TBFP8dReOCzcSpgo/q1yMdgA4KMvELCkKNvEgYzbPk=; b=TvcAETyzThqrHMhtc/eVdWCCXixHbrmALBESYz1jgcH8Rg+BFan0rsKF0+dbhMPkQRCAjt52GJ6z9n8KJo97NcCdTITBuIjMiNoGCGolOKJvfwR3DAEBxG400uHSwjsjlXT+gQ5Sccz89iZ0wfbUNPE818vLJrutto+mg/LI39Y11Gm15P3y7GuSsC+t4Cyk9oKiR4WDPWeXBd0/YLFB8d6zRQV7IV65g07G9/tnuTcaeC+4bItJhPv9a5SbW1amByf8LfLHehagCeb9azDhk69DhBhewUAJ2xskCHXw2kBBmzpD8dG2lyKKbV4GL/qFP2dYIY0N5s/zyeRFsH46Nw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+TBFP8dReOCzcSpgo/q1yMdgA4KMvELCkKNvEgYzbPk=; b=Ci8xBBcC3UMnC87UtpKQ1w56+WROxHW6m79uNvstKY2sS+4GhOn0qu22BB75rz4YdKjeH2dYP89svI93P0XVHPPHEshX54yMHpZEU/adDaxU5Mp7cybpoVKewqunXMqOZR0H54tgrmD/DPpBhU+yeF/qniApK6Ue2nDFbrjMad0= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6480.eurprd04.prod.outlook.com (20.179.233.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 15 Oct 2019 13:44:28 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee%5]) with mapi id 15.20.2347.023; Tue, 15 Oct 2019 13:44:28 +0000 From: Akhil Goyal To: Akhil Goyal , Julien Meunier , Pablo de Lara , Declan Doherty CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] cryptodev: fix invalid dev_id after a pmd close Thread-Index: AQHVTPuxVkGJ/cCU406+sl6dA4Y3kadJNPRwgBLt5MA= Date: Tue, 15 Oct 2019 13:44:28 +0000 Message-ID: References: <20190807083946.39309-1-julien.meunier@nokia.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c03825b6-b9ec-434d-9fc0-08d75175cc9d x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6480:|VE1PR04MB6480: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(189003)(199004)(478600001)(71190400001)(71200400001)(14454004)(2906002)(66066001)(33656002)(6116002)(8936002)(3846002)(25786009)(7736002)(229853002)(44832011)(486006)(66476007)(66556008)(64756008)(66446008)(11346002)(446003)(476003)(110136005)(54906003)(9686003)(55016002)(6246003)(86362001)(6436002)(76176011)(99286004)(7696005)(66946007)(316002)(81156014)(296002)(81166006)(8676002)(256004)(14444005)(305945005)(186003)(26005)(52536014)(74316002)(5660300002)(76116006)(4326008)(6506007)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6480; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LGrcBu61eu6BKDW7T40CFv8nP/mhOjpD69TpuqB9dcnkBi1C2ml+GyqeXQ0fuET0eOS9DoaNNxh39+tnNa2lXE98N0lFq0xi0ViSdGNNXy8tPVYq2SnybETQH52nwAVFrxmORJYMXRXQLOe6moef3fT6w5rH1m5qy/c+hvNntNuVu6c8eLXfk5nhtqmsLvDajothvK/RZhcS2n4J9b4ieK1pr2nWkdb+D+s+uWBU2NqKttc1EkVt8byQnGg+ooJa9F6DQfhQIb2IL2RCkBb5kgKwg6I2045tTvqhzXXUA9ut0nhRiCo2jlqFfsd32skZmhmCwlXAh7yGieliJTuaa2uo5jdngQmnm1Jp2K02SltqLzddSB+fQiISTO8dYCyQKPRYf/c4hYbb23LBnDwFVyHRIqJgw1/Yu8ALJcMF90M= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: c03825b6-b9ec-434d-9fc0-08d75175cc9d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 13:44:28.0491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZZrSLREhBZsMWfTQdPNCGo4fi/KSR+r8TfWy5zio5TZeeMbiuV96ZzBiCiJOwxp+dNfxptuBuAOGT79pzjl5tg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6480 Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix invalid dev_id after a pmd close 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" >=20 > Hi Julien >=20 > > > > Each cryptodev are indexed with its dev_id in the global > > rte_crypto_devices variable. nb_devs is incremented / decremented each > > time a cryptodev is created / deleted. The goal of nb_devs is to preven= t > > the user to get an invalid dev_id. > > > > Let's imagine DPDK has configured N cryptodevs. If the cryptodev=3D1 is > > removed at runtime, the latest cryptodev N cannot be accessible, becaus= e > > nb_devs=3DN-1. > > > > In order to prevent this kind of behavior, let's remove the check with > > nb_devs and iterate in all the rte_crypto_devices elements: if data is > > not NULL, that means a valid cryptodev is available. > > > > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto > > devices") > > Cc: stable@dpdk.org > > > > Signed-off-by: Julien Meunier > > --- // snip//=20 > > @@ -560,7 +570,13 @@ rte_cryptodev_get_dev_id(const char *name) > > uint8_t > > rte_cryptodev_count(void) > > { > > - return cryptodev_globals.nb_devs; > > + uint8_t i, dev_count =3D 0; > > + > > + for (i =3D 0; i < RTE_CRYPTO_MAX_DEVS; i++) > > + if (cryptodev_globals.devs[i].data !=3D NULL) > > + dev_count++; > > + > > + return dev_count; > > } >=20 > Why do you want to remove the nb_devs? We can have it updated > (incremented/decremented) > While allocate/release of the device. > The point is, whenever somebody call rte_cryptodev_count() it will do a l= ookup > of valid data > pointer. Could you please do the requested change. This patch need to be integrated = by this week. Thanks.