[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1276522483.2478.88.camel@edumazet-laptop>
Date: Mon, 14 Jun 2010 15:34:43 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: John Fastabend <john.r.fastabend@...el.com>, fubar@...ibm.com,
davem@...emloft.net, nhorman@...driver.com,
bonding-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [PATCH v2] net: deliver skbs on inactive slaves to exact
matches
From: John Fastabend <john.r.fastabend@...el.com>
Le lundi 14 juin 2010 à 16:21 +0300, Michael S. Tsirkin a écrit :
> On Thu, Jun 03, 2010 at 12:30:11PM -0700, John Fastabend wrote:
> > Currently, the accelerated receive path for VLAN's will
> > drop packets if the real device is an inactive slave and
> > is not one of the special pkts tested for in
> > skb_bond_should_drop(). This behavior is different then
> > the non-accelerated path and for pkts over a bonded vlan.
> >
> > For example,
> >
> > vlanx -> bond0 -> ethx
> >
> > will be dropped in the vlan path and not delivered to any
> > packet handlers at all. However,
> >
> > bond0 -> vlanx -> ethx
> >
> > and
> >
> > bond0 -> ethx
> >
> > will be delivered to handlers that match the exact dev,
> > because the VLAN path checks the real_dev which is not a
> > slave and netif_recv_skb() doesn't drop frames but only
> > delivers them to exact matches.
> >
> > This patch adds a sk_buff flag which is used for tagging
> > skbs that would previously been dropped and allows the
> > skb to continue to skb_netif_recv(). Here we add
> > logic to check for the deliver_no_wcard flag and if it
> > is set only deliver to handlers that match exactly. This
> > makes both paths above consistent and gives pkt handlers
> > a way to identify skbs that come from inactive slaves.
> > Without this patch in some configurations skbs will be
> > delivered to handlers with exact matches and in others
> > be dropped out right in the vlan path.
> >
> > I have tested the following 4 configurations in failover modes
> > and load balancing modes.
> >
> > # bond0 -> ethx
> >
> > # vlanx -> bond0 -> ethx
> >
> > # bond0 -> vlanx -> ethx
> >
> > # bond0 -> ethx
> > |
> > vlanx -> --
> >
> > Signed-off-by: John Fastabend <john.r.fastabend@...el.com>
>
> I am using qemu with both tap and slirp (userspace) networking.
> This works fine under 2.6.35-rc2 but breaks under 2.6.35-rc3:
> ssh over slirp stops working sometimes right away
> and sometimes after a bit of use, connection times out.
>
> Git bisect gave me this commit:
> 597a264b1a9c7e36d1728f677c66c5c1f7e3b837.
>
> Reverting 597a264b1a9c7e36d1728f677c66c5c1f7e3b837 fixes the issue
> for me.
>
> I'm short for time now so didn't debug this further.
> I opened a bugzilla to track this issue:
> https://bugzilla.kernel.org/show_bug.cgi?id=16204
>
A fix is already there, and bug is already opened multiple times.
http://lkml.org/lkml/2010/6/13/155
[PATCH] net: fix deliver_no_wcard regression on loopback device
deliver_no_wcard is not being set in skb_copy_header.
In the skb_cloned case it is not being cleared and
may cause the skb to be dropped when the loopback device
pushes it back up the stack.
Signed-off-by: John Fastabend <john.r.fastabend@...el.com>
Acked-by: Eric Dumazet <eric.dumazet@...il.com>
---
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 9f07e74..bcf2fa3 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -532,6 +532,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->ip_summed = old->ip_summed;
skb_copy_queue_mapping(new, old);
new->priority = old->priority;
+ new->deliver_no_wcard = old->deliver_no_wcard;
#if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
new->ipvs_property = old->ipvs_property;
#endif
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists