This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] network misbehaviour with gplpv and 2.6.30

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] network misbehaviour with gplpv and 2.6.30
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 18 Jul 2009 13:42:11 +1000
Cc: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Delivery-date: Fri, 17 Jul 2009 20:42:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoHWbvozKdGqiiiQgGZYpP1obczbA==
Thread-topic: network misbehaviour with gplpv and 2.6.30
With GPLPV under 2.6.30, GPLPV gets the following from the ring:

ring slot n (first buffer):
 status (length) = 54 bytes
 offset = 0
 flags = NETRXF_extra_info (possibly csum too but not relevant)
ring slot n + 1 (extra info)
 gso.size (mss) = 1460

Because NETRXF_extra_info is not set, that's all I get for that packet.
In the IP header though, the total length is 1544 (which in itself is a
little strange), but obviously I'm not getting a full packet, just the
ETH+IP+TCP header.

According to Andrew Lyon it works fine in previous versions, so this
problem only arises on 2.6.30. I don't know if netfront on Linux suffers
from a similar problem.

I can't identify any changes that could cause this, but if the problem
is in netback either the frags count isn't being set correctly, or
skb->cb (which appears to be used temporarily to hold nr_frags) is
becoming corrupt (set to 0) somehow, but the window where this could
occur is very small and I can't see where it could happen.

Any suggestions as to where to start looking?

(one nice thing is that I have identified a crash that would occur when
the IP header lied about its length!)



Xen-devel mailing list