DPDK patches and discussions
 help / color / mirror / Atom feed
From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: Marc Sune <marc.sune@bisdn.de>, "<dev@dpdk.org>" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Memory corruption in librte_ether?
Date: Mon, 20 Oct 2014 17:31:29 +0000	[thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8972262DBA9@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <5441873F.90500@bisdn.de>

Hi Marc,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marc Sune
> Sent: Friday, October 17, 2014 10:17 PM
> To: <dev@dpdk.org>
> Subject: [dpdk-dev] Memory corruption in librte_ether?
> 
> Hi all,
> 
> I was rebasing the KNI mempool v4 patch(I have it finalised, but wanted
> to check) to the latest master HEAD
> (075e064089e1c2b6899db58c69be1a387eb5ffa7) when I ran into problems
> with
> the current KNI example with em interfaces in a VM. I then switched to
> master's head and retried (so without the KNI mempool patch!) with the
> *same behaviour*. Behaviour here listed is with master head, so nothing
> to do with the patch I am working on.
> 
> The *VM*, emulated with qemu has 4 e1000 interfaces attached to several
> bridges. qmeu version 1.1.2 running in debian 7 64bit. With this setup I
> get the error:
> 
[...] 
> Which seems to indicate rte_eth_dev_info_get() is somehow corrupting
> memory(?¿). But I haven't figure out the problem (yet). I suspect of:
> 
> commit fbde27f19ab8f1d386868275bd8c016e693cf073
> Author: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Date:   Wed Oct 1 10:49:04 2014 +0100
> 
>      ethdev: get default Rx/Tx configuration from dev info
> 
>      Many sample apps use duplicated code to set rte_eth_txconf and
> rte_eth_rxconf
>      structures. This patch allows the user to get a default optimal
> RX/TX configuration
>      through rte_eth_dev_info get, and still any parameters may be
> tweaked as wished,
>      before setting up queues.
> 
>      Besides, if a NULL pointer is passed to rte_eth_rx_queue_setup or
>      rte_eth_tx_queue_setup, these functions get internally the default
> RX/TX
>      configuration for the user.
> 
>      Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
>      Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
>      Acked-by: David Marchand <david.marchand@6wind.com>
>      [Thomas: split patch]
> 
> commit a30268e9a2d0618902e8cf96b90b27db4fb02d54
> Author: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Date:   Wed Oct 1 10:49:03 2014 +0100
> 
>      ethdev: reset whole dev info structure before filling
> 
>      To guarantee that RX/TX configuration structures are reseted
>      before modifying them, plus the other dev info fields,
>      dev info structure is zeroed beforehand.
> 
>      Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
>      Acked-by: David Marchand <david.marchand@6wind.com>
> 
> 
> Can anyone confirm it?

I just pushed a fix for that problem. Indeed, the dev_info structure was polluted, 
because I was calling the specific dev_info_get function in the PMDs, 
and not calling rte_eth_dev_info_get in rte_ethdev.c, which means that
 the dev_info structure was not being reseted. 
In your case, em PMD does not overwrite the rte_eth_rxconf and 
rte_eth_txconf structures, and then you find random data in those structures.
Well spotted and thanks very much for all the details. 
I would appreciate if you could verify that this patch works for you.

Thanks,
Pablo
> 
> Marc
> 
> p.s. Has someone managed to run a dpdk app with valgrind?

  reply	other threads:[~2014-10-20 17:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 21:16 Marc Sune
2014-10-20 17:31 ` De Lara Guarch, Pablo [this message]
2014-10-21  8:12   ` Marc Sune

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=E115CCD9D858EF4F90C690B0DCB4D8972262DBA9@IRSMSX108.ger.corp.intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    --cc=marc.sune@bisdn.de \
    /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).