diff mbox

[net-next,4/7] openvswitch: Reset upper layer protocol info on internal devices.

Message ID 1342823210-3308-5-git-send-email-jesse@nicira.com
State Accepted, archived
Delegated to: David Miller
Headers show

Commit Message

Jesse Gross July 20, 2012, 10:26 p.m. UTC
It's possible that packets that are sent on internal devices (from
the OVS perspective) have already traversed the local IP stack.
After they go through the internal device, they will again travel
through the IP stack which may get confused by the presence of
existing information in the skb. The problem can be observed
when switching between namespaces. This clears out that information
to avoid problems but deliberately leaves other metadata alone.
This is to provide maximum flexibility in chaining together OVS
and other Linux components.

Signed-off-by: Jesse Gross <jesse@nicira.com>
---
 net/openvswitch/vport-internal_dev.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Jesse Gross Sept. 4, 2012, 12:57 a.m. UTC | #1
On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse@nicira.com> wrote:
> It's possible that packets that are sent on internal devices (from
> the OVS perspective) have already traversed the local IP stack.
> After they go through the internal device, they will again travel
> through the IP stack which may get confused by the presence of
> existing information in the skb. The problem can be observed
> when switching between namespaces. This clears out that information
> to avoid problems but deliberately leaves other metadata alone.
> This is to provide maximum flexibility in chaining together OVS
> and other Linux components.
>
> Signed-off-by: Jesse Gross <jesse@nicira.com>

It was recently discovered that the bug that this patch fixes is
causing problems in the real world.  Can you please queue this for
stable in 3.4/3.5?  It's currently in Linus's tree as
7fe99e2d434eafeac0c57b279a77e5de39212636.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Sept. 4, 2012, 1 a.m. UTC | #2
From: Jesse Gross <jesse@nicira.com>
Date: Mon, 3 Sep 2012 17:57:39 -0700

> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>> It's possible that packets that are sent on internal devices (from
>> the OVS perspective) have already traversed the local IP stack.
>> After they go through the internal device, they will again travel
>> through the IP stack which may get confused by the presence of
>> existing information in the skb. The problem can be observed
>> when switching between namespaces. This clears out that information
>> to avoid problems but deliberately leaves other metadata alone.
>> This is to provide maximum flexibility in chaining together OVS
>> and other Linux components.
>>
>> Signed-off-by: Jesse Gross <jesse@nicira.com>
> 
> It was recently discovered that the bug that this patch fixes is
> causing problems in the real world.  Can you please queue this for
> stable in 3.4/3.5?  It's currently in Linus's tree as
> 7fe99e2d434eafeac0c57b279a77e5de39212636.
> 

What vendor is shipping openvswitch enabled and requires the fix to
be in -stable before they'll ship it to customers?

That goes into what is 'real world'
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jesse Gross Sept. 4, 2012, 1:07 a.m. UTC | #3
On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem@davemloft.net> wrote:
> From: Jesse Gross <jesse@nicira.com>
> Date: Mon, 3 Sep 2012 17:57:39 -0700
>
>> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>>> It's possible that packets that are sent on internal devices (from
>>> the OVS perspective) have already traversed the local IP stack.
>>> After they go through the internal device, they will again travel
>>> through the IP stack which may get confused by the presence of
>>> existing information in the skb. The problem can be observed
>>> when switching between namespaces. This clears out that information
>>> to avoid problems but deliberately leaves other metadata alone.
>>> This is to provide maximum flexibility in chaining together OVS
>>> and other Linux components.
>>>
>>> Signed-off-by: Jesse Gross <jesse@nicira.com>
>>
>> It was recently discovered that the bug that this patch fixes is
>> causing problems in the real world.  Can you please queue this for
>> stable in 3.4/3.5?  It's currently in Linus's tree as
>> 7fe99e2d434eafeac0c57b279a77e5de39212636.
>>
>
> What vendor is shipping openvswitch enabled and requires the fix to
> be in -stable before they'll ship it to customers?
>
> That goes into what is 'real world'

Fedora is running into it I believe.  Chris Wright asked for it so he
might be able to elaborate more on their plans.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Sept. 4, 2012, 6:22 p.m. UTC | #4
From: Jesse Gross <jesse@nicira.com>
Date: Mon, 3 Sep 2012 18:07:29 -0700

> On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem@davemloft.net> wrote:
>> From: Jesse Gross <jesse@nicira.com>
>> Date: Mon, 3 Sep 2012 17:57:39 -0700
>>
>>> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>>>> It's possible that packets that are sent on internal devices (from
>>>> the OVS perspective) have already traversed the local IP stack.
>>>> After they go through the internal device, they will again travel
>>>> through the IP stack which may get confused by the presence of
>>>> existing information in the skb. The problem can be observed
>>>> when switching between namespaces. This clears out that information
>>>> to avoid problems but deliberately leaves other metadata alone.
>>>> This is to provide maximum flexibility in chaining together OVS
>>>> and other Linux components.
>>>>
>>>> Signed-off-by: Jesse Gross <jesse@nicira.com>
>>>
>>> It was recently discovered that the bug that this patch fixes is
>>> causing problems in the real world.  Can you please queue this for
>>> stable in 3.4/3.5?  It's currently in Linus's tree as
>>> 7fe99e2d434eafeac0c57b279a77e5de39212636.
>>>
>>
>> What vendor is shipping openvswitch enabled and requires the fix to
>> be in -stable before they'll ship it to customers?
>>
>> That goes into what is 'real world'
> 
> Fedora is running into it I believe.  Chris Wright asked for it so he
> might be able to elaborate more on their plans.

Anyways, I've meanwhile queued it up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chris Wright Sept. 4, 2012, 6:23 p.m. UTC | #5
* Jesse Gross (jesse@nicira.com) wrote:
> On Mon, Sep 3, 2012 at 6:00 PM, David Miller <davem@davemloft.net> wrote:
> > From: Jesse Gross <jesse@nicira.com>
> > Date: Mon, 3 Sep 2012 17:57:39 -0700
> >
> >> On Fri, Jul 20, 2012 at 3:26 PM, Jesse Gross <jesse@nicira.com> wrote:
> >>> It's possible that packets that are sent on internal devices (from
> >>> the OVS perspective) have already traversed the local IP stack.
> >>> After they go through the internal device, they will again travel
> >>> through the IP stack which may get confused by the presence of
> >>> existing information in the skb. The problem can be observed
> >>> when switching between namespaces. This clears out that information
> >>> to avoid problems but deliberately leaves other metadata alone.
> >>> This is to provide maximum flexibility in chaining together OVS
> >>> and other Linux components.
> >>>
> >>> Signed-off-by: Jesse Gross <jesse@nicira.com>
> >>
> >> It was recently discovered that the bug that this patch fixes is
> >> causing problems in the real world.  Can you please queue this for
> >> stable in 3.4/3.5?  It's currently in Linus's tree as
> >> 7fe99e2d434eafeac0c57b279a77e5de39212636.
> >>
> >
> > What vendor is shipping openvswitch enabled and requires the fix to
> > be in -stable before they'll ship it to customers?
> >
> > That goes into what is 'real world'
> 
> Fedora is running into it I believe.  Chris Wright asked for it so he
> might be able to elaborate more on their plans.

I've not hit the bug myself, but been made aware of the issue from
OpenStack/Quantum folks.

There's a testing scenario that hits this as described in this launchpad
bug:

  https://bugs.launchpad.net/quantum/+bug/1044318

thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/net/openvswitch/vport-internal_dev.c b/net/openvswitch/vport-internal_dev.c
index de509d3..4061b9e 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -24,6 +24,9 @@ 
 #include <linux/ethtool.h>
 #include <linux/skbuff.h>
 
+#include <net/dst.h>
+#include <net/xfrm.h>
+
 #include "datapath.h"
 #include "vport-internal_dev.h"
 #include "vport-netdev.h"
@@ -209,6 +212,11 @@  static int internal_dev_recv(struct vport *vport, struct sk_buff *skb)
 	int len;
 
 	len = skb->len;
+
+	skb_dst_drop(skb);
+	nf_reset(skb);
+	secpath_reset(skb);
+
 	skb->dev = netdev;
 	skb->pkt_type = PACKET_HOST;
 	skb->protocol = eth_type_trans(skb, netdev);