From: Cong Wang <xiyou.wangcong@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, Eilon Greenstein <eilong@broadcom.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Bruce Allan <bruce.w.allan@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
Don Skidmore <donald.c.skidmore@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
Alex Duyck <alexander.h.duyck@intel.com>,
John Ronciak <john.ronciak@intel.com>,
Tushar Dave <tushar.n.dave@intel.com>,
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>,
Sony Chacko <sony.chacko@qlogic.com>,
linux-driver@qlogic.com,
John Fastabend <john.r.fastabend@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Jacob Keller <jacob.e.keller@intel.com>,
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
Date: Thu, 07 Feb 2013 11:25:13 +0800 [thread overview]
Message-ID: <51131E99.8080400@gmail.com> (raw)
In-Reply-To: <cover.1360191528.git.mst@redhat.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <xiyou.wangcong@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eilon Greenstein <eilong@broadcom.com>,
John Fastabend <john.r.fastabend@intel.com>,
e1000-devel@lists.sourceforge.net,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Sony Chacko <sony.chacko@qlogic.com>,
bhutchings@solarflare.com,
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>,
netdev@vger.kernel.org, Bruce Allan <bruce.w.allan@intel.com>,
linux-kernel@vger.kernel.org,
John Ronciak <john.ronciak@intel.com>,
linux-driver@qlogic.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
Date: Thu, 07 Feb 2013 11:25:13 +0800 [thread overview]
Message-ID: <51131E99.8080400@gmail.com> (raw)
In-Reply-To: <cover.1360191528.git.mst@redhat.com>
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
next prev parent reply other threads:[~2013-02-07 3:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 23:02 [PATCH 0/2] fix kernel crash with macvtap on top of LRO Michael S. Tsirkin
2013-02-06 23:02 ` Michael S. Tsirkin
2013-02-06 23:02 ` [PATCH 1/2] ixgbe: fix gso type Michael S. Tsirkin
2013-02-06 23:02 ` Michael S. Tsirkin
2013-02-07 3:21 ` Eric Dumazet
2013-02-06 23:02 ` [PATCH 2/2] qlcnic: set gso_type Michael S. Tsirkin
2013-02-06 23:02 ` Michael S. Tsirkin
2013-02-07 3:20 ` Eric Dumazet
2013-02-07 8:16 ` Michael S. Tsirkin
2013-02-07 8:16 ` Michael S. Tsirkin
2013-02-06 23:34 ` [PATCH 0/2] fix kernel crash with macvtap on top of LRO Ben Hutchings
2013-02-06 23:34 ` Ben Hutchings
2013-02-07 3:18 ` Eric Dumazet
2013-02-07 3:18 ` Eric Dumazet
2013-02-07 16:20 ` Ben Hutchings
2013-02-07 16:20 ` Ben Hutchings
2013-02-07 18:14 ` David Miller
2013-02-07 18:14 ` David Miller
2013-02-07 21:33 ` Michael S. Tsirkin
2013-02-07 21:33 ` Michael S. Tsirkin
2013-02-07 22:31 ` Ben Hutchings
2013-02-07 22:31 ` Ben Hutchings
2013-02-11 1:15 ` David Miller
2013-06-10 7:07 ` Michael S. Tsirkin
2013-06-10 7:07 ` Michael S. Tsirkin
2013-06-12 14:56 ` Ben Hutchings
2013-06-12 14:56 ` Ben Hutchings
2013-06-12 19:00 ` Michael S. Tsirkin
2013-06-12 19:00 ` Michael S. Tsirkin
2013-06-17 1:35 ` Rusty Russell
2013-06-17 1:35 ` Rusty Russell
2013-06-17 16:20 ` Ben Hutchings
2013-06-17 16:20 ` Ben Hutchings
2013-06-18 5:12 ` Rusty Russell
2013-06-18 5:12 ` Rusty Russell
2013-02-07 3:25 ` Cong Wang [this message]
2013-02-07 3:25 ` Cong Wang
2013-02-07 8:15 ` Michael S. Tsirkin
2013-02-07 8:15 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51131E99.8080400@gmail.com \
--to=xiyou.wangcong@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhutchings@solarflare.com \
--cc=bruce.w.allan@intel.com \
--cc=carolyn.wyborny@intel.com \
--cc=davem@davemloft.net \
--cc=donald.c.skidmore@intel.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=eilong@broadcom.com \
--cc=eric.dumazet@gmail.com \
--cc=gregory.v.rose@intel.com \
--cc=jacob.e.keller@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=jitendra.kalsaria@qlogic.com \
--cc=john.r.fastabend@intel.com \
--cc=john.ronciak@intel.com \
--cc=linux-driver@qlogic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=sony.chacko@qlogic.com \
--cc=tushar.n.dave@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.