[dpdk-dev] [PATCH] virtio: fix packet corruption

Olivier Matz olivier.matz at 6wind.com
Tue Jul 19 15:59:51 CEST 2016


Hi,

On 07/19/2016 03:57 PM, Tan, Jianfeng wrote:
> 
> 
>> -----Original Message-----
>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>> Sent: Tuesday, July 19, 2016 9:11 PM
>> To: Tan, Jianfeng; dev at dpdk.org; Xie, Huawei; yuanhan.liu at linux.intel.com
>> Subject: Re: [PATCH] virtio: fix packet corruption
>>
>> Hi Jianfeng,
>>
>> On 07/19/2016 03:03 PM, Tan, Jianfeng wrote:
>>> Hi Oliver,
>>>
>>>> -----Original Message-----
>>>> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
>>>> Sent: Tuesday, July 19, 2016 8:32 PM
>>>> To: dev at dpdk.org; Tan, Jianfeng; Xie, Huawei;
>> yuanhan.liu at linux.intel.com
>>>> Subject: [PATCH] virtio: fix packet corruption
>>>>
>>>> The support of virtio-user changed the way the mbuf dma address is
>>>> retrieved, using a physical address in case of virtio-pci and a virtual
>>>> address in case of virtio-user.
>>>>
>>>> This change introduced some possible memory corruption in packets,
>>>> replacing:
>>>>   m->buf_physaddr + RTE_PKTMBUF_HEADROOM
>>>> by:
>>>>   m->buf_physaddr + m->data_off     (through a macro)
>>>>
>>>> This patch fixes this issue, restoring the original behavior.
>>>
>>> Could you be more specific on why we cannot use m->data_off here?
>>
>> There is no guarantee that m->data_off == RTE_PKTMBUF_HEADROOM here
>> as
>> virtqueue_enqueue_recv_refill() is called on a mbuf that is just
>> allocated with rte_mbuf_raw_alloc(). An alternative would be to set
>> data_off to RTE_PKTMBUF_HEADROOM, but as it's a fix and we are close to
>> the release, I prefered to restore the initial behavior.
> 
> Oh yes, gotcha.
> 
> But if we do not set data_off properly, it's still buggy when others consume these mbufs, right?
> 

This is done later in virtio_recv_pkts*() functions, one the host has
written the data in the mbuf.



More information about the dev mailing list