Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2013-02-07 08:11:49
Also in:
lkml
On Thu, Feb 07, 2013 at 11:25:13AM +0800, Cong Wang wrote:
On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote:quoted
At the moment, macvtap crashes are observed if macvtap is attached to an interface with LRO enabled. The crash in question is BUG() in macvtap_skb_to_vnet_hdr. This happens because several drivers set gso_size but not gso_type in incoming skbs. The following patches fix this for Additionally, cbf1de72324a8105ddcc3d9ce9acbc613faea17e is required to fix this for broadcom - would it make sense to cherry-pick this patch into 3.8?Doesn't macvtap need to call skb_warn_if_lro() too like bridge and openvswitch? Something like...
This is what Ben proposed a year ago http://thread.gmane.org/gmane.linux.network/221695 but apparently people really want LRO to work with macvtap.
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index b181dfb..b2c6227 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c@@ -253,6 +253,9 @@ static int macvtap_forward(struct net_device*dev, struct sk_buff *skb) if (!q) goto drop; + if (unlikely(skb_warn_if_lro(skb))) + goto drop; + if (skb_queue_len(&q->sk.sk_receive_queue) >= dev->tx_queue_len) goto drop; I am not saying these drivers don't need to fix, I am just saying if we need to fix LRO case. Thanks.
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired