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 F3070A0093; Mon, 18 May 2020 11:48:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D14471D514; Mon, 18 May 2020 11:48:24 +0200 (CEST) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120098.outbound.protection.outlook.com [40.107.12.98]) by dpdk.org (Postfix) with ESMTP id 8E6F91D514 for ; Mon, 18 May 2020 11:48:23 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iD1dh2wZ3HHxu6f6JLJF9jhyR8S9j11Z3b0lFg0/6pKqJwvQ3YZUoWXzirkZ+8kuZ9Jdoxdw7bc4lx4tpa6HNtxoXUccLHbr6+gLIwt+XyePY1EdydRVJBcCS4BF5SukdNFkmytndXUZsc2Z34FKkA7Tf/azByga4Y7ar5PQ1a2KGA4pmeqBjwfdUGyADy0DlWJqJ3MAvqiIdP59AOA/x+MmyxYWMioI9srPd4esGc/xhc4UjiVZBGaJMHxYFF7Rz4dTygRxv7cVW9lG4o2ntqVH7gVU/0nedfveaAYyTAAgMub+c52WgZZ952myR9FMH3awVO6EYWRp/1gvDp/4KQ== 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=4DivBMc5eoaGRQCk9f+UM2swdRV9HjN2w0HnPMesHAY=; b=j+9mI9P1qbHAJ6CEu/B/yeM1X2ZiyuyMTm2286gKFSt1h2KjsPl6KalFhcrWbV2XLb9xe0LvMrqrY4waBW/RBIrBl10Hux/7fgO3uEqv3W1t1ZjZrEaLU6Xp8dBUbvnxsw4sSpzPu5o27fClwH6i/OMt0c50Iu6024vKoaAApvphg6It2ayyFVMTbFQYe5XD5FBuLWMSSDGBuf0o7domwIwQdm08qoWuPiJ/gv8TqG8Rzc+BovivUCoKuIJl/tMj6BNJJm+ehaf7VVnLGM9MQU8aTBv1XtaDek4U+yIWS5GlqghtrzDTLJ4Dj1qqwbFl/YeS8YiRlbkuvPS+re2Yiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ekinops.com; dmarc=pass action=none header.from=ekinops.com; dkim=pass header.d=ekinops.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ekinops.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4DivBMc5eoaGRQCk9f+UM2swdRV9HjN2w0HnPMesHAY=; b=OeOlmrPSDM7/TdqMmemG43UblzEjKEkBFGS3gHYXY9dYBk2ilkj78OLCIU8lWFLyNDZ4YTyAkpvZ4fPcMzJ+aDSRIVxrhCb1k0DU4AeK/zvL9hsDf7bJ1umejhH3bzwdk2dNAgkuu6Ct1WC7JW4Y+M25fBqTKsASK4UOHGSceNE= Received: from MRXP264MB0325.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:22::19) by MRXP264MB0775.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:24::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.27; Mon, 18 May 2020 09:48:22 +0000 Received: from MRXP264MB0325.FRAP264.PROD.OUTLOOK.COM ([fe80::41a7:e761:6112:5c08]) by MRXP264MB0325.FRAP264.PROD.OUTLOOK.COM ([fe80::41a7:e761:6112:5c08%7]) with mapi id 15.20.3000.034; Mon, 18 May 2020 09:48:22 +0000 From: Renata Saiakhova To: Ferruh Yigit , "dev@dpdk.org" CC: Anatoly Burakov , Thomas Monjalon , Neil Horman Thread-Topic: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings allocation Thread-Index: AQHWKSiBVnQ5DV9vGkK2sZRAv+g9WqimIkcAgAdv15s= Date: Mon, 18 May 2020 09:48:22 +0000 Message-ID: References: <20200513131425.27817-1-Renata.Saiakhova@ekinops.com>, <7e3ef1e4-cca6-c113-3d15-648265d3072f@intel.com> In-Reply-To: <7e3ef1e4-cca6-c113-3d15-648265d3072f@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=ekinops.com; x-originating-ip: [2a02:a03f:8b18:1c00:1508:b5de:e9ba:7c4e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7037a828-edff-4c9b-4205-08d7fb109a8c x-ms-traffictypediagnostic: MRXP264MB0775: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Yc7b/jllj6yImsbjO33dRhvA4SuNyHRJO7rwQPho0DjMBoNgJemL4ap1xyEw/pRipayDLrJ6wO5sMBjsKXnSSbftRCJaSlVcdvseTvcM0B2RLRtGxT0gwORon/7Ch7/zaoNUzIp1nnqDJE43Ti87eXLQIpWxq83hyfIrkIxDSasuGtsdEe6gpRNNimUGuCV81A6Sx6MWkUqnvCATfamy7ZFuN/MstEm0Q9sby2EH9DCVvqJVO+ViwTvBIuwYlI7i8ZMi90tfwqc46XCwE7M2MSMpZK0Ipy5AUfsfbREDSWMgqqhlko8K3kty0lsF1XXOmJSpixRQTGJxJuJJN0Ty0zOCuYfQccJdVv09wR5aMEm2tfad9bM/JlzzfJA8GK1z13cSALoovP+/Dny3yJDdLe+n/1wSaCNjF8mQG/bssHfGOtdKwdZcb8VqScK2qfWm x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MRXP264MB0325.FRAP264.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(346002)(396003)(366004)(39840400004)(136003)(376002)(55016002)(2906002)(4326008)(76116006)(52536014)(66446008)(66946007)(66556008)(66476007)(64756008)(186003)(6506007)(110136005)(316002)(54906003)(19627405001)(53546011)(86362001)(7696005)(44832011)(71200400001)(9686003)(33656002)(8676002)(8936002)(478600001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ES3Szw11+U8UFitGSzV2d5hhGvzr5Njc7A1aTCBD4Qk/lzyRibnoktiqyFc7byRZok7oF1ndRYC+pZQ8NyPm21zQRZLiVGN1swIFSCRF0JGlG1cuAg92txfaA/o0eT81NICFx8XfF4S9tiPtpJF9fZCQVYXIHnaerhcTl3lHUltC9ZDjAu+R0A7hTT/3F98G3mQtrXHKj+4mdoRZZIJ7TuEhcsZq0tcetkisHAympff51C8eLCcjT35y6MeUTZUPUV8Bnu2dgDRxfAaIIv17YlYwYS00Im7dl8xV5+YXJrjD50DbyqqtEZHbNV1x8ZXKdWN7dzX7dCzJFfhcRHKUIqISsQRY8S2vdHko9FWFp+A9JQsNXxlGvV45xU3Ig4ZupQUTh2ug3D6Pg1A2EnEWYedeW5+QTti/0iH4boEKQ0uvsnNj7KNwl9wUVGeLyfcCK4D8w94ZDDIT+D7K3oXjnDgBNKL7lKEXdp8zvsCCGC+RoNKonrK/x8yE+v/S1J6+i5LKHb5uZFiStIgRQCDDCJlVzQjclUZTr7qpBqGKv3U= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: ekinops.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7037a828-edff-4c9b-4205-08d7fb109a8c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 09:48:22.6476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f57b78a6-c654-4771-a72f-837275f46179 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: D5JU07aAAT5Jwkn0/9aTHo5hj2ouzrf0O5ANgO66qlz8nrOSR+Ufm5Gn5QoB1Mm1OZrqkG/BcQ+ntvkHV/nBmTYud8A4NAzCkP+/7DSIcoc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MRXP264MB0775 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings allocation 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 Ferruh, thanks for comments, are the rte_eth_dma_zone_reserve() calls always used to allocate HW rings? = It is not totally clear to me. That was partly the reason I don't do the fi= x for every driver which uses this API. I made fixes in the drivers which u= ses the same pattern to allocate / release queues, for other drivers I was = not sure but anyway I couldn't spend more time for further investigations. = In the company I work for we use dpdk for our project and maintain it in se= parate tree, and the vulnerability with HW rings is a real issue for igb an= d ixgbe drivers and needs to be fixed. Therefore I would like this patch to= be accepted in order to not maintain the fix ourselves. But unfortunately = I don't have resources (e.g. time) to fix the issue for all the drivers, be= cause, as I mentioned, they are not following the same pattern to release t= heir queues. So my proposal is that I fix it in this patch in a number of d= rivers (including igb, ixgbe and i40e) and others can take over and improve= other drivers, if they see the same issue. This is also a reason why the d= rivers' changes are not in one commit for all the drivers. For the proposal adding pmd name as prefix to queue memzone name or update = the 'rte_eth_dma_zone_reserve()' to check the size & alignment instead of j= ust a name, I don't know, as an external person, how sensitive dpdk project= to change an internal API and existing code (the call should be changed in= all the drivers). But anyway, I think the real problem is more an absence = of memzone pointer, and in long term it should be solved in this way, rathe= r than search by name. Kind regards, Renata ________________________________ From: Ferruh Yigit Sent: Wednesday, May 13, 2020 5:22 PM To: Renata Saiakhova ; dev@dpdk.org Cc: Anatoly Burakov ; Thomas Monjalon ; Neil Horman Subject: Re: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings al= location On 5/13/2020 2:14 PM, Renata Saiakhova wrote: > igb and ixgbe and some other drivers allocate HW rings using rte_eth_dma_= zone_reserve(), > which checks first if the memzone exists for a given name, consisting of = port > id, queue_id, rx/tx direction, but not for the size, alignment, and socke= t_id. > If the memzone with a given name exists it is returned, otherwise it is > allocated. > Disconnecting dpdk port from one type of interface (igb) and connecting i= t > to another type of interface (ixgbe) for the same port id, potentially cr= eates > memory overlap and corruption, because it may require memzone of bigger s= ize. > That's what is happening from switching from igb to ixgbe having the same= port > id. > > v2->v3: Remove #undef ETH_DMA_MZONE_NAME and minor changes in code standa= rd > v1->v2: Minor changes on code standard and additional fixes in i40e em an= d ice drivers > > Renata Saiakhova (4): > librte_ethdev: Introduce a function to release HW rings > drivers/net: Fix in igb and ixgbe HW rings memory > drivers/net: Fix in i40e HW rings memory overlap > drivers/net: Fix in em and ice HW rings memory overlap I think all driver patches can be squashed into single patch, overall they = are implementing same logic. But as mentioned before, there are multiple other drivers allocating HW rin= gs with exact same name. At least I can see: iavf nfp fm10k axgbe Or how can we know if a new PMD won't cause exact same behavior? What to yo= u think adding pmd name as prefix to queue memzone name for all PMDs? This ca= n help new PMDs using existing code as sample. I don't know if it has been discussed before, but wouldn't update the 'rte_eth_dma_zone_reserve()' to check the size & alignment instead of just = name fix the issue for all drivers without needing to update them?