[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1276462246.2448.17.camel@edumazet-laptop>
Date: Sun, 13 Jun 2010 22:50:46 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: John Fastabend <john.r.fastabend@...el.com>
Cc: David Miller <davem@...emloft.net>,
"markus@...ppelsdorf.de" <markus@...ppelsdorf.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
yanmin_zhang@...ux.intel.com, alex.shi@...el.com,
tim.c.chen@...el.com
Subject: Re: mpd client timeouts (bisected) 2.6.35-rc3
Le dimanche 13 juin 2010 à 13:36 -0700, John Fastabend a écrit :
> John Fastabend wrote:
> > David Miller wrote:
> >> From: Markus Trippelsdorf <markus@...ppelsdorf.de>
> >> Date: Sat, 12 Jun 2010 12:28:02 +0200
> >>
> >>> Commit 597a264b1a9c7e36d1728f677c66c5c1f7e3b837:
> >>> »net: deliver skbs on inactive slaves to exact matches«
> >>>
> >>> causes large timeouts when mpd clients try to connect to a locally
> >>> running mpd (music player demon) on my machine. This makes it
> >>> impossible to control mpd.
> >>>
> >>> I bisected this down to the commit mentioned above.
> >>> Reverting the commit from 2.6.35-rc3 also solves the problem.
> >> John, find an easy and fast way to fix this or else I am
> >> going to revert.
> >>
> >> Thanks.
> >
> > Looks like skbs are hitting loopback_xmit() with deliver_no_wcard set. Then in
> > the receive path these skbs are only delivered to exact matches. Not sure why
> > this bit is set here, I'll track this down first thing tomorrow.
> >
> > Thanks,
> > John.
> > --
>
> Needed to set the wcard bit in copy_skb_header otherwise it will not be cleared
> when called from skb_clone. Which then hits the loopback device gets pushed
> into the rx path and is eventually dropped. The following patch fixes this.
> Hopefully, this is easy and fast enough for you Dave.
>
>
> [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>
> ---
>
> net/core/skbuff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> 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
> --
Acked-by: Eric Dumazet <eric.dumazet@...il.com>
BTW, David, it seems there is a double rxhash copy...
[PATCH] net: rxhash already set in __copy_skb_header
No need to copy rxhash again in __skb_clone()
Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
---
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 9f07e74..a58e63b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -569,7 +569,6 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
C(len);
C(data_len);
C(mac_len);
- C(rxhash);
n->hdr_len = skb->nohdr ? skb_headroom(skb) : skb->hdr_len;
n->cloned = 1;
n->nohdr = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists