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 1EAC7A04EF; Wed, 3 Jun 2020 03:36:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 595F21BFCC; Wed, 3 Jun 2020 03:36:41 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id CF3261BF83 for ; Wed, 3 Jun 2020 03:36:38 +0200 (CEST) IronPort-SDR: QgQiYscgpI0837e3CzmSe9Yj4Y6bWE8jpbpiWnbeeu1gFiwIQlvkFnnePH12+KdPWFA0xuZein jDVFoDZKWaow== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2020 18:36:36 -0700 IronPort-SDR: v6ABstlBUDT9jU/kMDdV98q0spF68HwOfOWR3SMOiqQ8Lmcm4Xnv0hTrmegNLobjk0d4yXm/WG JCNkKBW1w2dg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,466,1583222400"; d="scan'208";a="268909871" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 02 Jun 2020 18:36:35 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 2 Jun 2020 18:36:35 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 2 Jun 2020 18:36:35 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.52) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 2 Jun 2020 18:36:35 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aj57HEHLm0q6Qhv3ceIGp24/NmlrQEYM6xNICSDMTsN9Jg0Ikcq5U4+oTRzvGYJRHjcy6jUdXbr0S5bWuSoREL7mYDfwEscN82g27XC+YuwSjI3sW/MZPTnaE9UiLdq8krqEWqmE14ohwP9VE+2m+Ewa1Yv1oB3IwIg6WCc/SRtItG3/Uf6kWaqlrkAKqloxQH+WBIzZ29LSJCcwRibMJsk98GgdBWlLYZt4LcMj/wn7dRBfM9sbuRWuLUwQ/t28Ixhcek72DYHBZM8e8S1kWEP5rQDi7ePiEGt6zbNLcvoOsRzIMYsWPqz1jG5ak41vxA2/4XZB2PrttAMeGUvjcA== 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=wOJ9LOxKQAEZ8QIFHV38IpKcxftaVvN7DsvrMuoC8tY=; b=DxnstvsyZ3DkQOJkfZ3dsTlaFTh48YrBtVgALMZRYKw2BPgOU/DybfVkQYrPVF+TW0A5a7UL7Gq4P46jEm9Ad5t7lKaHDQwLI/rjGpX+BbA4bZdNF0zkv+DJ613OXqRmag4o/2hZ+eMTDVHXFzBKo7GZdqiia2IBUYCsLKs+TBohAKdpBnfTA7y3boyHPKMTzBIc8CuTxIA2wu2+vEBZG04PgptjYu3YS81VP+7iEovIeGnXqjI7SEA879uaV45c99dZ39uvTDchSv89Qwi+qSQdDMifeKLdpmeJBEAH70seNURTFOnK3V2VsOEvqx8p65JW7yLayShBqFZEvG2QkQ== 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=wOJ9LOxKQAEZ8QIFHV38IpKcxftaVvN7DsvrMuoC8tY=; b=N42PCAA1YF8J7ojM45vyPuO/teXMGAQdBDzYELf/S/IojXR1b161cmckW5UZBUemsEJA86e0u8T5fEUULEskJ8SxUTuqWzdff2vTuPR9T1A33PdRfx1o0KPSC6+iyhxoKdMCUYyXgTYwxe7a1SzTtI+ApbpT1L85KWBdLfiU4vI= Received: from MWHPR11MB1391.namprd11.prod.outlook.com (2603:10b6:300:23::15) by MWHPR11MB1549.namprd11.prod.outlook.com (2603:10b6:301:c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.22; Wed, 3 Jun 2020 01:36:34 +0000 Received: from MWHPR11MB1391.namprd11.prod.outlook.com ([fe80::c809:34b4:173b:d211]) by MWHPR11MB1391.namprd11.prod.outlook.com ([fe80::c809:34b4:173b:d211%7]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 01:36:33 +0000 From: "Zhao1, Wei" To: Renata Saiakhova , "Yigit, Ferruh" , "dev@dpdk.org" CC: "Burakov, Anatoly" , Thomas Monjalon , Neil Horman Thread-Topic: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings allocation Thread-Index: AQHWKTqL09fT510adkulf6vGwQr7LaitoHoAgBiY26A= Date: Wed, 3 Jun 2020 01:36:33 +0000 Message-ID: References: <20200513131425.27817-1-Renata.Saiakhova@ekinops.com>, <7e3ef1e4-cca6-c113-3d15-648265d3072f@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjc0NGVkZGItMjBkZi00N2E1LWI2NmItYTBmYTEzZDIxODZiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTUFveTBhbDRUV2dVMG9GOTdpK1hleDRmTXNSZEJaNXVXSnpHNVBqODkrUXMzbmpPNFlhckVSMlZtN1cwdlRVNyJ9 dlp-version: 11.0.600.7 dlp-product: dlpe-windows x-ctpclassification: CTP_NT dlp-reaction: no-action authentication-results: ekinops.com; dkim=none (message not signed) header.d=none;ekinops.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.55.52.209] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 035134f0-0112-45d9-6b49-08d8075e8c93 x-ms-traffictypediagnostic: MWHPR11MB1549: 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:10000; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JOtoQGAp9/fPu0Xc2D4UHbOhBPUrxGf3SOvvV90W0HdCKW8e+QkEXpl2Z5xlKI5ZXlE0iD52Rjh0YbzLuBysOHS/EJhQdC8d6O6KpEngGRd652u/bRmRWVgGyWH3osdISugdwEwwGjn6l6MpGoMLHOswq0BQkIcEUxH5oNFZbk3dAjEEnI0QDpV3urqOLPvny90WS02+phbLtwT75E25oe6Ll/RLjE1QfwN5kD5JbZcfhEEhxJAMdWn/N1P+rgwQ4BKSKZHHd1kODcp29aChoQptdtLjEqXw89OSXGtKAhS9tyh32XAyME5ue/i3WUt/kBDs3eclmRoSix33DJMBbA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1391.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(136003)(39850400004)(366004)(376002)(396003)(83380400001)(8676002)(8936002)(33656002)(66446008)(66946007)(64756008)(66556008)(55016002)(9686003)(4326008)(66476007)(76116006)(6506007)(86362001)(2906002)(53546011)(478600001)(186003)(26005)(52536014)(54906003)(5660300002)(110136005)(71200400001)(316002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: EJTUbEKYkiXVKEGHGySdfQ38I6C0kolAc/1w3pyD4pL9/eRGNfsJTeclCn7yGIvq4giJBMM+InTcinIMPEsGjrNr/7YN1WjkaTYli9vBL1XUN8GSwqmQFGAzBHRcx4//rbhvk5VF0kdY2QNt7+63lT8pv+QERVZCneKOmqrBxeg5wE3aDOSJ4DBco3QjWQpFZHl5/IfXNnEb1hcsV38iMBX46nicYKnbC/YdP2DgXzTEVAqJ2X/y5SxYQD/GMC2v1Ql4zXnf4lhuaYgM+8WZCsd7S94lYi7qaX2PPEFTDOZ/dfEeXZd/LGYGwAYAxQoofAniXFV9cpkHRa6tMoD3sj/06Z+zSZi2oIMXToQT7kmUSpZSBGpW4yUVpQWRZWm7EbByCQ2c0DAeOxRud9DwzTyBPapRG+iIOx2lr4vPRob4VxTkRQFtT61uCrL4mEqbx+EAYXOLAgXWDl/lNQs/lMZb9YU7wOmf5JQ9LvhOagE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 035134f0-0112-45d9-6b49-08d8075e8c93 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 01:36:33.7707 (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: 843CBzYJ77NRgpMjw3Tkz+qEi01LDgfIUriw4C7ARWjXrkPuYpitJzYbps3cmTu74tHamhXNe65JN056R9swRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1549 X-OriginatorOrg: intel.com 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" I am sure i40e FDIR filter also allocate ring for filter programing, it als= o has the same issue. Ice NIC the same. Although we can avoid this issue by change ring name to "igb_tx_ring" and s= o on, but the issue of memory for ring not freed after close is still exsit= . Support this comment. If no one take over all the work for all the PMD, we = had better accept this patch. > -----Original Message----- > From: dev On Behalf Of Renata Saiakhova > Sent: Monday, May 18, 2020 5:48 PM > To: Yigit, Ferruh ; dev@dpdk.org > Cc: Burakov, Anatoly ; Thomas Monjalon > ; Neil Horman > Subject: Re: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings > allocation >=20 > Hi Ferruh, >=20 > thanks for comments, >=20 > 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 fix= for every > driver which uses this API. I made fixes in the drivers which uses the sa= me > pattern to allocate / release queues, for other drivers I was not sure bu= t > anyway I couldn't spend more time for further investigations. In the comp= any I > work for we use dpdk for our project and maintain it in separate tree, an= d the > vulnerability with HW rings is a real issue for igb and ixgbe drivers and= needs to > be fixed. Therefore I would like this patch to be accepted in order to no= t > maintain the fix ourselves. But unfortunately I don't have resources (e.g= . time) > to fix the issue for all the drivers, because, as I mentioned, they are n= ot > following the same pattern to release their queues. So my proposal is tha= t I fix > it in this patch in a number of drivers (including igb, ixgbe and i40e) a= nd others > can take over and improve other drivers, if they see the same issue. This= is also > a reason why the drivers' changes are not in one commit for all the drive= rs. >=20 > 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 just a name, I don't know, as an external person, how sensitiv= e dpdk > project to change an internal API and existing code (the call should be c= hanged > in all the drivers). But anyway, I think the real problem is more an abse= nce of > memzone pointer, and in long term it should be solved in this way, rather= than > search by name. >=20 > 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 > allocation >=20 > 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 socket_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 it to another type of interface (ixgbe) for the same port > > id, potentially creates memory overlap and corruption, because it may > require memzone of bigger size. > > 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 > > v2->standard > > v1->v2: Minor changes on code standard and additional fixes in i40e em > > v1->and 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 >=20 > I think all driver patches can be squashed into single patch, overall the= y are > implementing same logic. >=20 > But as mentioned before, there are multiple other drivers allocating HW r= ings > with exact same name. At least I can see: > iavf > nfp > fm10k > axgbe >=20 > Or how can we know if a new PMD won't cause exact same behavior? What to > you think adding pmd name as prefix to queue memzone name for all PMDs? > This can help new PMDs using existing code as sample. >=20 > 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 jus= t > name fix the issue for all drivers without needing to update them?