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 B9B1FA051A; Fri, 19 Jun 2020 18:54:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CB4641BF70; Fri, 19 Jun 2020 18:54:33 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id E203F1BF67 for ; Fri, 19 Jun 2020 18:54:31 +0200 (CEST) IronPort-SDR: RX92Y2hKJbeHbaHmbbi7StNfmX2rp+3V5hkevg7N7gTbMx56yY1V6C5Jttvxj/ekEC2WwS+Swl 8ujLHoYSqE/g== X-IronPort-AV: E=McAfee;i="6000,8403,9657"; a="123283492" X-IronPort-AV: E=Sophos;i="5.75,256,1589266800"; d="scan'208";a="123283492" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2020 09:54:30 -0700 IronPort-SDR: 5Gt1CGI1eXs4iCOfFHkhYBtuD65XxjIVn30UyL5nZc8QCkKhV52v/NVJ1koTaFkE1WyOYlkwh9 zseV4ML9rXig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,256,1589266800"; d="scan'208";a="264463114" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.243.128]) ([10.213.243.128]) by orsmga007.jf.intel.com with ESMTP; 19 Jun 2020 09:54:29 -0700 To: Renata Saiakhova , "dev@dpdk.org" Cc: Anatoly Burakov , Thomas Monjalon , Neil Horman References: <20200513131425.27817-1-Renata.Saiakhova@ekinops.com> <7e3ef1e4-cca6-c113-3d15-648265d3072f@intel.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJsBBMBCgBWAhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEABQkKqZZ8FiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl6ha3sXGHZrczovL2tl eXMub3BlbnBncC5vcmcACgkQ+TPrQ98TYR8uLA//QwltuFliUWe60xwmu9sY38c1DXvX67wk UryQ1WijVdIoj4H8cf/s2KtyIBjc89R254KMEfJDao/LrXqJ69KyGKXFhFPlF3VmFLsN4XiT PSfxkx8s6kHVaB3O183p4xAqnnl/ql8nJ5ph9HuwdL8CyO5/7dC/MjZ/mc4NGq5O9zk3YRGO lvdZAp5HW9VKW4iynvy7rl3tKyEqaAE62MbGyfJDH3C/nV/4+mPc8Av5rRH2hV+DBQourwuC ci6noiDP6GCNQqTh1FHYvXaN4GPMHD9DX6LtT8Fc5mL/V9i9kEVikPohlI0WJqhE+vQHFzR2 1q5nznE+pweYsBi3LXIMYpmha9oJh03dJOdKAEhkfBr6n8BWkWQMMiwfdzg20JX0o7a/iF8H 4dshBs+dXdIKzPfJhMjHxLDFNPNH8zRQkB02JceY9ESEah3wAbzTwz+e/9qQ5OyDTQjKkVOo cxC2U7CqeNt0JZi0tmuzIWrfxjAUulVhBmnceqyMOzGpSCQIkvalb6+eXsC9V1DZ4zsHZ2Mx Hi+7pCksdraXUhKdg5bOVCt8XFmx1MX4AoV3GWy6mZ4eMMvJN2hjXcrreQgG25BdCdcxKgqp e9cMbCtF+RZax8U6LkAWueJJ1QXrav1Jk5SnG8/5xANQoBQKGz+yFiWcgEs9Tpxth15o2v59 gXK5Ag0EV9ZMvgEQAKc0Db17xNqtSwEvmfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ES YpV8QWj0xK4YM0dLxnDU2IYxjEshSB1TqAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4Ai bPtrHuIXWQOBECcVZTTOdZYGAzaYzxiAONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxD UQljeNvKYt1lZE/gAUUxNLWsYyTT+22/vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/ 3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35piVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVj sM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQI3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdc q9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYHfVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH7 1PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZqw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFB VOQOxCvwRG2QCgcJ/UTn5vlivul+cThi6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI 8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJlRr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYC GwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNhHwUCXqFrngUJCKxSYAAKCRD5M+tD3xNhH3YWD/9b cUiWaHJasX+OpiuZ1Li5GG3m9aw4lR/k2lET0UPRer2Jy1JsL+uqzdkxGvPqzFTBXgx/6Byz EMa2mt6R9BCyR286s3lxVS5Bgr5JGB3EkpPcoJT3A7QOYMV95jBiiJTy78Qdzi5LrIu4tW6H o0MWUjpjdbR01cnj6EagKrDx9kAsqQTfvz4ff5JIFyKSKEHQMaz1YGHyCWhsTwqONhs0G7V2 0taQS1bGiaWND0dIBJ/u0pU998XZhmMzn765H+/MqXsyDXwoHv1rcaX/kcZIcN3sLUVcbdxA WHXOktGTQemQfEpCNuf2jeeJlp8sHmAQmV3dLS1R49h0q7hH4qOPEIvXjQebJGs5W7s2vxbA 5u5nLujmMkkfg1XHsds0u7Zdp2n200VC4GQf8vsUp6CSMgjedHeF9zKv1W4lYXpHp576ZV7T GgsEsvveAE1xvHnpV9d7ZehPuZfYlP4qgo2iutA1c0AXZLn5LPcDBgZ+KQZTzm05RU1gkx7n gL9CdTzVrYFy7Y5R+TrE9HFUnsaXaGsJwOB/emByGPQEKrupz8CZFi9pkqPuAPwjN6Wonokv ChAewHXPUadcJmCTj78Oeg9uXR6yjpxyFjx3vdijQIYgi5TEGpeTQBymLANOYxYWYOjXk+ae dYuOYKR9nbPv+2zK9pwwQ2NXbUBystaGyQ== Message-ID: Date: Fri, 19 Jun 2020 17:54:28 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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" On 5/18/2020 10:48 AM, Renata Saiakhova wrote: > 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 fix for every > driver which uses this API. I made fixes in the drivers which uses 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 separate tree, and 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 not > 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 not > following the same pattern to release their queues. So my proposal is that I fix > it in this patch in a number of drivers (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 drivers' 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 just 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, rather than search by > name. Hi Renata, 'rte_eth_dma_zone_reserve()' returning existing memzone just based on 'name' without checking the size, alignment, socket_id seems wrong to me, let me check it, it shouldn't be hard to update. But even 'rte_eth_dma_zone_reserve()' checks won't be enough (what to do if check fails and not returns a memzone?), the proper solution is PMD free the memzone as they removed, as done in this patch. Also I suggested prefixing the memzone name as workaround but instead we can go with this patchset with the implemented PMDs and other PMD owners can implement the free when they need instead of workaround. There is a comment from Wie to add more frees to i40e, and there is another from Jeff on 'rte_eth_dma_zone_free()' return type, can you please check them? So we can proceed with this patch for the release. Thanks, ferruh > > 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 >   > 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 standard >> v1->v2: Minor changes on code standard and additional fixes in i40e em 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 > > 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 rings > 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 you > think adding pmd name as prefix to queue memzone name for all PMDs? This can > 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?