[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e7757cf-148e-4585-b358-3b38f391275d@cambridgegreys.com>
Date: Mon, 24 Feb 2020 19:54:57 +0000
From: Anton Ivanov <anton.ivanov@...bridgegreys.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Network Development <netdev@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
linux-um@...ts.infradead.org,
"Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH v3] virtio: Work around frames incorrectly marked as gso
On 24/02/2020 19:27, Willem de Bruijn wrote:
> On Mon, Feb 24, 2020 at 8:26 AM <anton.ivanov@...bridgegreys.com> wrote:
>>
>> From: Anton Ivanov <anton.ivanov@...bridgegreys.com>
>>
>> Some of the locally generated frames marked as GSO which
>> arrive at virtio_net_hdr_from_skb() have no GSO_TYPE, no
>> fragments (data_len = 0) and length significantly shorter
>> than the MTU (752 in my experiments).
>
> Do we understand how these packets are generated?
No, we have not been able to trace them.
The only thing we know is that this is specific to locally generated
packets. Something arriving from the network does not show this.
> Else it seems this
> might be papering over a deeper problem.
>
> The stack should not create GSO packets less than or equal to
> skb_shinfo(skb)->gso_size. See for instance the check in
> tcp_gso_segment after pulling the tcp header:
>
> mss = skb_shinfo(skb)->gso_size;
> if (unlikely(skb->len <= mss))
> goto out;
>
> What is the gso_type, and does it include SKB_GSO_DODGY?
>
0 - not set.
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
Powered by blists - more mailing lists