[Saucy] [PATCH] SRU: zerocopy LSO segmenting fixed

[Luis Henriques]

Anton Nayshtut <anton at swortex.com> writes:

> Hi all,
>
> All relevant tests passed with the Ben's patch as well.
>
> Thus, it does suffice.
>
> Best Regards,
> Anton
>

Awesome, thanks for testing Anton!

I guess this means we can drop this patch and just wait for the next
cycle that starts next week (the last one before EOL).  Kernel
3.11.10.12, which includes this fix, will be released later this week
and included in the HWE saucy kernel.

Cheers,
-- 
Luís


> On Mon, Jun 23, 2014 at 7:52 PM, Anton Nayshtut <anton at swortex.com> wrote:
>> Hi Tim and Luis,
>>
>> We're testing the patch backported by Ben Hutching right now.
>>
>> Will update you once the tests are done.
>>
>> Best Regards,
>> Anton
>>
>> On Mon, Jun 23, 2014 at 5:06 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
>>> On 06/23/2014 07:53 AM, Luis Henriques wrote:
>>>>
>>>> On Sun, Jun 22, 2014 at 11:07:42AM +0300, Anton Nayshtut wrote:
>>>>>
>>>>> BugLink: https://bugs.launchpad.net/bugs/1328973
>>>>>
>>>>> [SRU Justification]
>>>>>
>>>>> [Setup]
>>>>>   - 2 or more QEMU Guest VMs sharing the the same host
>>>>>   - the Guests are communicating using virtio-net-pci devices
>>>>>   - vhost-net is enabled
>>>>>
>>>>> [Explanation]
>>>>> If one Guest VM sends GSO packets to another while GRO is disabled for
>>>>> receiver,
>>>>> so these packets are segmented by net/core.
>>>>> In this case, if zero-copy is enabled in vhost-net, the GSO packets TX
>>>>> completion is reported to userspace as before the TX is actually done.
>>>>> The vhost-net's zero-copy mechanism is enabled by default since v3.8-rc1
>>>>> (f9611c43).
>>>>>
>>>>> [Impact]
>>>>> Incorrect/junk data sent in case the transmitting Guest OS re-uses/frees
>>>>> the TX
>>>>> buffer immediately upon TX completion.
>>>>>
>>>>> [Test Case]
>>>>> Windows 2008R2 Guest VMs running MS HCK Offload LSO test.
>>>>> NOTE1: GRO is always disabled in this case because it's not supported by
>>>>> Windows
>>>>> Guest virtio-net-pci drivers.
>>>>> NOTE2: MS HCK re-uses the GSO (LSO) buffers, so it reproduces the issue
>>>>> every
>>>>> time.
>>>>>
>>>>>     skbuff: skb_segment: orphan frags before copying
>>>>>
>>>>>      skb_segment copies frags around, so we need
>>>>>      to copy them carefully to avoid accessing
>>>>>      user memory after reporting completion to userspace
>>>>>      through a callback.
>>>>>
>>>>>      skb_segment doesn't normally happen on datapath:
>>>>>      TSO needs to be disabled - so disabling zero copy
>>>>>      in this case does not look like a big deal.
>>>>>
>>>>>      OriginalAuthor: Michael S. Tsirkin <mst at redhat.com>
>>>>>      Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>>>>>      Acked-by: Herbert Xu <herbert at gondor.apana.org.au>
>>>>>      Signed-off-by: David S. Miller <davem at davemloft.net>
>>>>>
>>>>>      (cherry picked from commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f)
>>>>>      CVE-2014-0131
>>>>>      Signed-off-by: Andy Whitcroft <apw at canonical.com>
>>>>>      (backported from 0f860fb4f583909ed999df58abf57ff40ec94d6d
>>>>> ubuntu-trusty)
>>>>>      Signed-off-by: Anton Nayshtut <anton at swortex.com>
>>>>>
>>>>
>>>> This patch is included in the 3.11 extended stable currently under
>>>> review[1].  Since Saucy picks the 3.11 extended stable releases, this
>>>> patch would be included in the Saucy kernel anyway (Note:
>>>> lts-backport-saucy kernels are about to reach EOL!).
>>>>
>>>> However, the backport is I have for the 3.11 kernel is different[2]
>>>> from this one and I am not able to decide which is correct one.
>>>>
>>>> For the 3.11 kernel I have picked the version provided by Ben Hutching
>>>> to the stable mailing list[3].  This version is currently being used
>>>> in the Lucid kernel, and has been released on the 3.8 extended
>>>> stable.
>>>>
>>>> [1] https://lkml.org/lkml/2014/6/23/368
>>>> [2] https://lkml.org/lkml/2014/6/23/400
>>>> [3] http://thread.gmane.org/gmane.linux.kernel.stable/93422
>>>>
>>>> Cheers,
>>>> --
>>>> Luís
>>>>
>>>
>>> There does seem to be a small, but fundamental, difference.
>>>
>>> Anton - could you have a look to see if the upstream patch will suffice ?
>>> I'd prefer to go with what is coming up in stable because its been tested in
>>> Lucid.
>>>
>>> rtg
>>> --
>>> Tim Gardner tim.gardner at canonical.com