[dpdk-dev] Memory corruption in librte_ether?

[Marc Sune]

Pablo,

I've only tried with the kni-autotest but it seems to work fine. Thanks!

Btw, at least in my development VM the kni-autotest in the current head 
(455d09e i40e: generic filter control), but also in v1.7.1, fails:

RTE>>kni_autotest
master lcore: 0
count: 2
PMD: eth_em_rx_queue_setup(): sw_ring=0x7f27ab4e8100 
hw_ring=0x7f27aa600000 dma_addr=0x36e00000
PMD: eth_em_tx_queue_setup(): sw_ring=0x7f27ab4e6000 
hw_ring=0x7f27aa610000 dma_addr=0x36e10000
PMD: eth_em_start(): <<
KNI: pci: 00:06:00      8086:100e
KNI: Invalid KNI request operation.
KNI: Invalid kni info.
KNI: The KNI request operationhas already registered.
Change MTU of port 0 to 1450
Change MTU of port 0 to 1450 successfully.
KNI: Invalid kni info.
The ingress/egress number should not be less than 100
Test Failed
RTE>>

Maybe it is simply a lack of resources in the qemu VM.

Saludos
marc

On 20/10/14 19:31, De Lara Guarch, Pablo wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune
>> Sent: Friday, October 17, 2014 10:17 PM
>> To: <dev at 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 at 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 at intel.com>
>>       Reviewed-by: Bruce Richardson <bruce.richardson at intel.com>
>>       Acked-by: David Marchand <david.marchand at 6wind.com>
>>       [Thomas: split patch]
>>
>> commit a30268e9a2d0618902e8cf96b90b27db4fb02d54
>> Author: Pablo de Lara <pablo.de.lara.guarch at 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 at intel.com>
>>       Acked-by: David Marchand <david.marchand at 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?