DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhao1, Wei" <wei.zhao1@intel.com>
To: Renata Saiakhova <renata.saiakhova@ekinops.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings allocation
Date: Wed, 3 Jun 2020 01:36:33 +0000	[thread overview]
Message-ID: <MWHPR11MB1391FAA1D7013ACAD69C36AFB7880@MWHPR11MB1391.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MRXP264MB0325E7C0534A49174311FD8E92B80@MRXP264MB0325.FRAP264.PROD.OUTLOOK.COM>

I am sure i40e FDIR filter also allocate ring for filter programing, it also has the same issue. Ice NIC the same.
Although we can avoid this issue by change ring name to "igb_tx_ring" and so 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 <dev-bounces@dpdk.org> On Behalf Of Renata Saiakhova
> Sent: Monday, May 18, 2020 5:48 PM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; dev@dpdk.org
> Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Neil Horman <nhorman@tuxdriver.com>
> Subject: Re: [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings
> allocation
> 
> 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.
> 
> Kind regards,
> Renata
> ________________________________
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, May 13, 2020 5:22 PM
> To: Renata Saiakhova <renata.saiakhova@ekinops.com>; dev@dpdk.org
> <dev@dpdk.org>
> Cc: Anatoly Burakov <anatoly.burakov@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; Neil Horman <nhorman@tuxdriver.com>
> 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
> > 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
> 
> 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?

  reply	other threads:[~2020-06-03  1:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 13:14 Renata Saiakhova
2020-05-13 13:14 ` [dpdk-dev] [PATCH v3 1/4] librte_ethdev: Introduce a function to release HW rings Renata Saiakhova
2020-05-14 13:14   ` Burakov, Anatoly
2020-05-15  8:04   ` Jeff Guo
2020-06-19 17:06     ` Ferruh Yigit
2020-05-13 13:14 ` [dpdk-dev] [PATCH v3 2/4] drivers/net: Fix in igb and ixgbe HW rings memory Renata Saiakhova
2020-05-13 13:14 ` [dpdk-dev] [PATCH v3 3/4] drivers/net: Fix in i40e HW rings memory overlap Renata Saiakhova
2020-06-01  7:58   ` Zhao1, Wei
2020-06-19 16:56     ` Ferruh Yigit
2020-06-20  3:02       ` Zhao1, Wei
2020-05-13 13:14 ` [dpdk-dev] [PATCH v3 4/4] drivers/net: Fix in em and ice " Renata Saiakhova
2020-05-13 15:22 ` [dpdk-dev] [PATCH v3 0/4] Memory corruption due to HW rings allocation Ferruh Yigit
2020-05-18  9:48   ` Renata Saiakhova
2020-06-03  1:36     ` Zhao1, Wei [this message]
2020-06-19 16:54       ` Ferruh Yigit
2020-06-19 16:54     ` Ferruh Yigit
2020-06-22  9:59       ` Renata Saiakhova
2020-06-20  3:27 ` Zhao1, Wei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR11MB1391FAA1D7013ACAD69C36AFB7880@MWHPR11MB1391.namprd11.prod.outlook.com \
    --to=wei.zhao1@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=nhorman@tuxdriver.com \
    --cc=renata.saiakhova@ekinops.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).