Subject: Re: [Xen-devel] [PATCH 2/4] xen-netfront: drop skb when skb->len > 65535

From: Christoph Egger <[email-masked]>
Date: Tue, 9 Apr 2013 16:53:13 +0200

On 09.04.13 16:45, Ben Hutchings wrote:
> On Tue, 2013-04-09 at 15:30 +0100, Ian Campbell wrote:
>> On Tue, 2013-03-19 at 21:28 +0000, Ben Hutchings wrote:
>>> On Tue, 2013-03-19 at 21:24 +0000, Ben Hutchings wrote:
>>>> On Mon, 2013-03-18 at 15:07 +0000, Ian Campbell wrote:
>>>>> On Mon, 2013-03-18 at 15:04 +0000, Wei Liu wrote:
>>>>>> On Mon, 2013-03-18 at 14:54 +0000, Ian Campbell wrote:
>>>>>>> On Mon, 2013-03-18 at 14:40 +0000, Wei Liu wrote:
>>>>>>>> On Mon, 2013-03-18 at 11:42 +0000, Ian Campbell wrote:
>>>>>>>>> On Mon, 2013-03-18 at 10:35 +0000, Wei Liu wrote:
>>>>>>>>>> The `size' field of Xen network wire format is uint16_t, anything bigger than
>>>>>>>>>> 65535 will cause overflow.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Wei Liu <[email-masked]>
>>>>>>>>>> ---
>>>>>>>>>>   drivers/net/xen-netfront.c |   12 ++++++++++++
>>>>>>>>>>   1 file changed, 12 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>>>>>>>> index 5527663..8c3d065 100644
>>>>>>>>>> --- a/drivers/net/xen-netfront.c
>>>>>>>>>> +++ b/drivers/net/xen-netfront.c
>>>>>>>>>> @@ -547,6 +547,18 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>>>>>>   	unsigned int len = skb_headlen(skb);
>>>>>>>>>>   	unsigned long flags;
>>>>>>>>>>
>>>>>>>>>> +	/*
>>>>>>>>>> +	 * wire format of xen_netif_tx_request only supports skb->len
>>>>>>>>>> +	 * < 64K, because size field in xen_netif_tx_request is
>>>>>>>>>> +	 * uint16_t.
>>>>>>>>>
>>>>>>>>> Is there some field we can set e.g. in struct ethernet_device which
>>>>>>>>> would stop this from happening?
>>>>>>>>>
>>>>>>>>
>>>>>>>> struct ethernet_device? I could not find it.
>>>>>>>>
>>>>>>>> And for struct net_device,
>>>>>>>
>>>>>>> I meant struct net_device.
>>>>>>>
>>>>>>>>   there is no field for this AFAICT.
>>>>>>>
>>>>>>> Interesting. Are hardware devices expected to cope with arbitrary sized
>>>>>>> GSO skbs then I wonder.
>>>>>>>
>>>>>>
>>>>>> No idea. But there is a macro called GSO_MAX_SIZE (65536) in struct
>>>>>> net_device. :-)
>>>>>
>>>>> But aren't we seeing skb's bigger than that?
>>>>>
>>>>> Maybe this is just a historical bug in some older guests?
>>>>
>>>> GSO_MAX_SIZE is the maximum payload length, not the maximum total length
>>>> of an skb.
>>>
>>> ...and it's actually just the default value assigned to
>>> dev->gso_max_size.  You'll want to change it to your actual maximum
>>> (65535 - maximum length of headers) before registering your net devices.
>>
>> Thanks.
>>
>> "maximum length of headers" might be a bit tricky to determine
>> generically :-(.
>
> Well you don't need to be generic, you need to know the maximum length
> of headers that might appear in a TSO skb.
>
> Ethernet + VLAN tag + IPv6 + TCP + timestamp option = 90 bytes, but I'm
> not sure whether there can be other IP or TCP options in a TSO skb.  I'd
> really like to get the TSO requirements clearly documented somewhere.

What about encapsulated IPSEC, IP-in-IP-tunnels, etc. ?

Christoph