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 A7739A2F18 for ; Thu, 3 Oct 2019 14:49:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99AAF1C0B2; Thu, 3 Oct 2019 14:49:55 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.40]) by dpdk.org (Postfix) with ESMTP id 43A331C07B; Thu, 3 Oct 2019 14:49:54 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BvKKPrUV40flq8hPgJgADVJzsXhxetqiYPBcLG8/lXzpS0inC6cQXqY7GQKMEchGIYod64zDusvVxX/VsDfp8Afs38B1AYEUXAHzAbwkCrhxKlte8u/rQvJts+LEmzZNvJLBKuB/A4fckHpFqwlTXH5fzqp03Rck7T4LT5XkqqJ4rCA76HNRcFaGlzfy+BxmwBINjCLVkL2YbILvqNiDhfFW+Q6/H7mn5id/9bTmHUcuoujZDxhkXQ9mPoppo3tLoaMs/rBpxgKMoiVUxfq69N6q0R169EBK2YNRW/1ZgPYXnVJW3U7OChvUKxjd2YRFF5aWdN3Sx/LumZF5Kkl39g== 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=/YMzDy7CF79Y+IaCshB1hNtm1paNOPfiiVOGso5/iYc=; b=n+3IcJOgvS4P3I9OYZ8seOUd0z5BQll2g29QBuLV9NFzfnrkiOakdZ75ohDLxRshtlIATiFcnGobqbMAwmmQleDs0Ou+U9dVqNh91XXCQTdDjmf4g4Tzls1t8RXYNTfCpjC9B9fYpPibTArb5L0aL4wP6+4pmiuytfMnWzkmcmnIW37iKxAJKnpoet52Hwe86D5n1M6cFvdjq4ce8D0v7jw1aOGcmiaukC5QPNPpGID3kqGKClBoVJEr9xgiZ+hIeWWWwfytbCU6LZDRdfoCGowo7WTMD3zERWaKKogomu66rutuoVADTqs/gY5uscQ9x/b475LUyPkLieOg2kldtg== 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=/YMzDy7CF79Y+IaCshB1hNtm1paNOPfiiVOGso5/iYc=; b=hM4D5GFUjDTO4tK+p0ryF57nhGpcCYK/fwK4H7CM+T90Ul2QUjR3AxIAIimi5jerTgi80F8/jlmiwfidIdjDLyq5DSX97ZHVuE95H8NAFBxQZzLBAa/A1+4U4/tyJ3HSze5D+buLelSsce2CbMcYVDmZyPwulaIUYKHdpyMiebw= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6623.eurprd04.prod.outlook.com (20.179.235.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 12:49:53 +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.2305.023; Thu, 3 Oct 2019 12:49:53 +0000 From: Akhil Goyal To: 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+sl6dA4Y3kadJNPRw Date: Thu, 3 Oct 2019 12:49:53 +0000 Message-ID: References: <20190807083946.39309-1-julien.meunier@nokia.com> In-Reply-To: <20190807083946.39309-1-julien.meunier@nokia.com> 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: d5b1f8d5-3f27-46ad-fcf6-08d748002fb5 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6623: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(346002)(376002)(199004)(189003)(5024004)(256004)(6436002)(14444005)(305945005)(7736002)(26005)(74316002)(229853002)(476003)(4326008)(6506007)(11346002)(9686003)(55016002)(66066001)(486006)(478600001)(7696005)(76176011)(25786009)(6246003)(66946007)(71200400001)(71190400001)(186003)(99286004)(76116006)(66476007)(66556008)(64756008)(66446008)(44832011)(3846002)(296002)(6116002)(86362001)(316002)(52536014)(14454004)(54906003)(2906002)(33656002)(8676002)(102836004)(446003)(81166006)(110136005)(8936002)(81156014)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6623; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: faO8tOIaPDTFfaBFL/OKu73AbMmHabBb1iTsaaEImcQKbLhwkY4AvCBxP9vc1oyJo/FckAvMXPQGusOM9i0su5ybZUHz9gXdqYfKdgqQr0U2j1yu8YEnaYJw6/zOHPGikt0N+PaMW3QqxM5oMO0EvXDeK59Fuiozlmq6w4BCeYEplZqvZaOsK/LjU8FPezXkIwzXR180p8iW5U4q4Md0hmmM5coi7qRsxADBRg/gskiT9AKFdl5XwVD7o8E6FnwjLKtamrhmvxAhSsTr7atxM6QtVGO3CKUyIHrBw8bS46KRIFmHbflf7T88jdhGwrWlci0IrBPdFPIEYpqxp2Ytg0w0ZqK9+4BC5dbIV0BJJmy109+xMWuLzeEpUmNcz9blpa4PHvkvwb8XidObBZ59Vd837HzBSrVXwt5dGhLP4CU= x-ms-exchange-transport-forked: True 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: d5b1f8d5-3f27-46ad-fcf6-08d748002fb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 12:49:53.2750 (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: 5tZtJgfTOK/mERP/4+S9MTlhWngUOSxxZkCJmSDPeXHLE7jfhu+9vrYLPsWB/5ri+eSD/eHdVHn4ajK6jXZ5PQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6623 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" 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 prevent > the user to get an invalid dev_id. >=20 > Let's imagine DPDK has configured N cryptodevs. If the cryptodev=3D1 is > removed at runtime, the latest cryptodev N cannot be accessible, because > nb_devs=3DN-1. >=20 > 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. >=20 > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto > devices") > Cc: stable@dpdk.org >=20 > Signed-off-by: Julien Meunier > --- > lib/librte_cryptodev/rte_cryptodev.c | 42 ++++++++++++++++++++++++------= ---- > -- > 1 file changed, 28 insertions(+), 14 deletions(-) >=20 > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > b/lib/librte_cryptodev/rte_cryptodev.c > index 43bc335..c8c7ffd 100644 > --- a/lib/librte_cryptodev/rte_cryptodev.c > +++ b/lib/librte_cryptodev/rte_cryptodev.c > @@ -49,9 +49,7 @@ struct rte_cryptodev *rte_cryptodevs =3D rte_crypto_dev= ices; >=20 > static struct rte_cryptodev_global cryptodev_globals =3D { > .devs =3D rte_crypto_devices, > - .data =3D { NULL }, > - .nb_devs =3D 0, > - .max_devs =3D RTE_CRYPTO_MAX_DEVS > + .data =3D { NULL } > }; >=20 > /* spinlock for crypto device callbacks */ > @@ -512,7 +510,7 @@ rte_cryptodev_pmd_get_named_dev(const char *name) > if (name =3D=3D NULL) > return NULL; >=20 > - for (i =3D 0; i < cryptodev_globals.max_devs; i++) { > + for (i =3D 0; i < RTE_CRYPTO_MAX_DEVS; i++) { > dev =3D &cryptodev_globals.devs[i]; >=20 > if ((dev->attached =3D=3D RTE_CRYPTODEV_ATTACHED) && > @@ -523,12 +521,21 @@ rte_cryptodev_pmd_get_named_dev(const char > *name) > return NULL; > } >=20 > +static uint8_t > +rte_cryptodev_is_valid_device_data(uint8_t dev_id) > +{ > + if (rte_crypto_devices[dev_id].data =3D=3D NULL) > + return 0; > + > + return 1; > +} > + > unsigned int > rte_cryptodev_pmd_is_valid_dev(uint8_t dev_id) > { > struct rte_cryptodev *dev =3D NULL; >=20 > - if (dev_id >=3D cryptodev_globals.nb_devs) > + if (!rte_cryptodev_is_valid_device_data(dev_id)) > return 0; >=20 > dev =3D rte_cryptodev_pmd_get_dev(dev_id); > @@ -547,12 +554,15 @@ rte_cryptodev_get_dev_id(const char *name) > if (name =3D=3D NULL) > return -1; >=20 > - for (i =3D 0; i < cryptodev_globals.nb_devs; i++) > + for (i =3D 0; i < RTE_CRYPTO_MAX_DEVS; i++) { > + if (!rte_cryptodev_is_valid_device_data(i)) > + continue; > if ((strcmp(cryptodev_globals.devs[i].data->name, name) > =3D=3D 0) && > (cryptodev_globals.devs[i].attached =3D=3D > RTE_CRYPTODEV_ATTACHED)) > return i; > + } >=20 > return -1; > } > @@ -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; > } 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 loo= kup of valid data pointer. >=20 > uint8_t > @@ -568,7 +584,7 @@ rte_cryptodev_device_count_by_driver(uint8_t > driver_id) > { > uint8_t i, dev_count =3D 0; >=20 > - for (i =3D 0; i < cryptodev_globals.max_devs; i++) > + for (i =3D 0; i < RTE_CRYPTO_MAX_DEVS; i++) > if (cryptodev_globals.devs[i].driver_id =3D=3D driver_id && > cryptodev_globals.devs[i].attached =3D=3D > RTE_CRYPTODEV_ATTACHED) > @@ -583,9 +599,10 @@ rte_cryptodev_devices_get(const char *driver_name, > uint8_t *devices, > { > uint8_t i, count =3D 0; > struct rte_cryptodev *devs =3D cryptodev_globals.devs; > - uint8_t max_devs =3D cryptodev_globals.max_devs; >=20 > - for (i =3D 0; i < max_devs && count < nb_devices; i++) { > + for (i =3D 0; i < RTE_CRYPTO_MAX_DEVS && count < nb_devices; i++) { > + if (!rte_cryptodev_is_valid_device_data(i)) > + continue; >=20 > if (devs[i].attached =3D=3D RTE_CRYPTODEV_ATTACHED) { > int cmp; > @@ -736,8 +753,6 @@ rte_cryptodev_pmd_allocate(const char *name, int > socket_id) > TAILQ_INIT(&(cryptodev->link_intr_cbs)); >=20 > cryptodev->attached =3D RTE_CRYPTODEV_ATTACHED; > - > - cryptodev_globals.nb_devs++; > } >=20 > return cryptodev; > @@ -766,7 +781,6 @@ rte_cryptodev_pmd_release_device(struct > rte_cryptodev *cryptodev) > return ret; >=20 > cryptodev->attached =3D RTE_CRYPTODEV_DETACHED; > - cryptodev_globals.nb_devs--; > return 0; > } >=20 > @@ -1099,7 +1113,7 @@ rte_cryptodev_info_get(uint8_t dev_id, struct > rte_cryptodev_info *dev_info) > { > struct rte_cryptodev *dev; >=20 > - if (dev_id >=3D cryptodev_globals.nb_devs) { > + if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) { > CDEV_LOG_ERR("Invalid dev_id=3D%d", dev_id); > return; > } > -- > 2.10.2