Bug in hash changes to netback in 4.7.2 kernel

Bug in hash changes to netback in 4.7.2 kernel

[Anthony Wright]

When I run Xen (4.7.0) nested in VirtualBox (5.0.24_Ubuntu r108355) with a linux-4.7.2 Dom0 kernel, none of my DomU's (linux-3.17.3) have network connectivity because they reject all packets with the error 'Invalid extra type: 4'. When I run exactly the same setup on bare metal, I don't get the error messages.

From poking around in the code this seems to be because the 4.7.2 kernel wrongly decides that the DomU's will understand EXTRA_TYPE_HASH, and so attach it to the network packet. Since the DomU's don't understand the extra info their netfront driver rejects the whole packet.

I'm guessing that the nesting is confusing the new hash code.

I also wonder if the DomU's should simply ignore extra info that they don't understand rather than rejecting the packet.

Cheers,

Anthony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Bug in hash changes to netback in 4.7.2 kernel

[Paul Durrant]

> -----Original Message-----
> From: Anthony Wright [mailto:anthony@overnetdata.com]
> Sent: 06 September 2016 13:23
> To: Xen-devel <xen-devel@lists.xen.org>
> Cc: Paul Durrant <Paul.Durrant@citrix.com>
> Subject: Bug in hash changes to netback in 4.7.2 kernel
> 
> When I run Xen (4.7.0) nested in VirtualBox (5.0.24_Ubuntu r108355) with a
> linux-4.7.2 Dom0 kernel, none of my DomU's (linux-3.17.3) have network
> connectivity because they reject all packets with the error 'Invalid extra type:
> 4'. When I run exactly the same setup on bare metal, I don't get the error
> messages.
> 
> From poking around in the code this seems to be because the 4.7.2 kernel
> wrongly decides that the DomU's will understand EXTRA_TYPE_HASH, and so
> attach it to the network packet. Since the DomU's don't understand the extra
> info their netfront driver rejects the whole packet.
> 

The code in xenvif_select_queue() deliberately clears the skb->sw_hash field (which gates adding the new extra type) if the hash algorithm selected by the frontend is 'none', which should be the default. So, unless you have a frontend that is implementing the control ring protocol, but failing to recognize the new extra type I'm not how you're seeing the problem... unless somehow a packet which hash is getting into netback's start_xmit without first having gone through select_queue?

> I'm guessing that the nesting is confusing the new hash code.
> 
> I also wonder if the DomU's should simply ignore extra info that they don't
> understand rather than rejecting the packet.
> 

Yes, that would certainly be sensible.

   Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Bug in hash changes to netback in 4.7.2 kernel

[Anthony Wright]

On 06/09/2016 13:57, Paul Durrant wrote:
>> -----Original Message-----
>> From: Anthony Wright [mailto:anthony@overnetdata.com]
>> Sent: 06 September 2016 13:23
>> To: Xen-devel <xen-devel@lists.xen.org>
>> Cc: Paul Durrant <Paul.Durrant@citrix.com>
>> Subject: Bug in hash changes to netback in 4.7.2 kernel
>>
>> When I run Xen (4.7.0) nested in VirtualBox (5.0.24_Ubuntu r108355) with a
>> linux-4.7.2 Dom0 kernel, none of my DomU's (linux-3.17.3) have network
>> connectivity because they reject all packets with the error 'Invalid extra type:
>> 4'. When I run exactly the same setup on bare metal, I don't get the error
>> messages.
>>
>> From poking around in the code this seems to be because the 4.7.2 kernel
>> wrongly decides that the DomU's will understand EXTRA_TYPE_HASH, and so
>> attach it to the network packet. Since the DomU's don't understand the extra
>> info their netfront driver rejects the whole packet.
> The code in xenvif_select_queue() deliberately clears the skb->sw_hash field (which gates adding the new extra type) if the hash algorithm selected by the frontend is 'none', which should be the default. So, unless you have a frontend that is implementing the control ring protocol, but failing to recognize the new extra type I'm not how you're seeing the problem... unless somehow a packet which hash is getting into netback's start_xmit without first having gone through select_queue?
I very much doubt that the frontend is implementing the control ring
protocol, the DomUs are running stock linux-3.17.3. I build the system
from source, so happy to re-compile with debug code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Bug in hash changes to netback in 4.7.2 kernel

[Paul Durrant]

> -----Original Message-----
> From: Anthony Wright [mailto:anthony@overnetdata.com]
> Sent: 06 September 2016 14:37
> To: Paul Durrant <Paul.Durrant@citrix.com>; Xen-devel <xen-
> devel@lists.xen.org>
> Subject: Re: Bug in hash changes to netback in 4.7.2 kernel
> 
> On 06/09/2016 13:57, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Anthony Wright [mailto:anthony@overnetdata.com]
> >> Sent: 06 September 2016 13:23
> >> To: Xen-devel <xen-devel@lists.xen.org>
> >> Cc: Paul Durrant <Paul.Durrant@citrix.com>
> >> Subject: Bug in hash changes to netback in 4.7.2 kernel
> >>
> >> When I run Xen (4.7.0) nested in VirtualBox (5.0.24_Ubuntu r108355)
> >> with a
> >> linux-4.7.2 Dom0 kernel, none of my DomU's (linux-3.17.3) have
> >> network connectivity because they reject all packets with the error
> 'Invalid extra type:
> >> 4'. When I run exactly the same setup on bare metal, I don't get the
> >> error messages.
> >>
> >> From poking around in the code this seems to be because the 4.7.2
> >> kernel wrongly decides that the DomU's will understand
> >> EXTRA_TYPE_HASH, and so attach it to the network packet. Since the
> >> DomU's don't understand the extra info their netfront driver rejects the
> whole packet.
> > The code in xenvif_select_queue() deliberately clears the skb->sw_hash
> field (which gates adding the new extra type) if the hash algorithm selected
> by the frontend is 'none', which should be the default. So, unless you have a
> frontend that is implementing the control ring protocol, but failing to
> recognize the new extra type I'm not how you're seeing the problem...
> unless somehow a packet which hash is getting into netback's start_xmit
> without first having gone through select_queue?
> I very much doubt that the frontend is implementing the control ring
> protocol, the DomUs are running stock linux-3.17.3. I build the system from
> source, so happy to re-compile with debug code.

Well, if you could have a look to see whether the skbs have sw_hash set when they get into net_rx_action() that would be something, and also check whether xenvif_select_queue() is being properly called. I'll take a look and see if I can repro this myself when I get some time.

  Paul

  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Bug in hash changes to netback in 4.7.2 kernel

[Todd Fleisher]

Has there been any update to this bug/issue last discussed on Tue 6 Sep 2016 14:37:21 +0100? Under Debian stretch running Xen & kernel version 4.8.0-1-amd64 I have a Windows HVM that cannot communicate with other PVM domU instances on the same dom0. The PVM domU instances report: "net eth0: Invalid extra type: 4”.

-T


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel