Re: Bug in hash changes to netback in 4.7.2 kernel

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----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