From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757534Ab3BGDZa (ORCPT ); Wed, 6 Feb 2013 22:25:30 -0500 Received: from mail-ia0-f175.google.com ([209.85.210.175]:62574 "EHLO mail-ia0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754330Ab3BGDZZ (ORCPT ); Wed, 6 Feb 2013 22:25:25 -0500 Message-ID: <51131E99.8080400@gmail.com> Date: Thu, 07 Feb 2013 11:25:13 +0800 From: Cong Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: netdev@vger.kernel.org, Eilon Greenstein , Jeff Kirsher , Jesse Brandeburg , Bruce Allan , Carolyn Wyborny , Don Skidmore , Greg Rose , Peter P Waskiewicz Jr , Alex Duyck , John Ronciak , Tushar Dave , Jitendra Kalsaria , Sony Chacko , linux-driver@qlogic.com, John Fastabend , "David S. Miller" , Jacob Keller , linux-kernel@vger.kernel.org, e1000-devel@lists.sourceforge.net, bhutchings@solarflare.com, eric.dumazet@gmail.com Subject: Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote: > 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... 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cong Wang Subject: Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO Date: Thu, 07 Feb 2013 11:25:13 +0800 Message-ID: <51131E99.8080400@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Eilon Greenstein , John Fastabend , e1000-devel@lists.sourceforge.net, Jesse Brandeburg , Jacob Keller , Sony Chacko , bhutchings@solarflare.com, Jitendra Kalsaria , netdev@vger.kernel.org, Bruce Allan , linux-kernel@vger.kernel.org, John Ronciak , linux-driver@qlogic.com, "David S. Miller" To: "Michael S. Tsirkin" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: e1000-devel-bounces@lists.sourceforge.net List-Id: netdev.vger.kernel.org On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote: > 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... 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