From: Eric Dumazet <eric.dumazet@gmail.com>
To: John Fastabend <john.r.fastabend@intel.com>
Cc: David Miller <davem@davemloft.net>,
"markus@trippelsdorf.de" <markus@trippelsdorf.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
yanmin_zhang@linux.intel.com, alex.shi@intel.com,
tim.c.chen@intel.com
Subject: Re: mpd client timeouts (bisected) 2.6.35-rc3
Date: Sun, 13 Jun 2010 22:50:46 +0200 [thread overview]
Message-ID: <1276462246.2448.17.camel@edumazet-laptop> (raw)
In-Reply-To: <4C15414E.5090201@intel.com>
Le dimanche 13 juin 2010 à 13:36 -0700, John Fastabend a écrit :
> John Fastabend wrote:
> > David Miller wrote:
> >> From: Markus Trippelsdorf <markus@trippelsdorf.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@intel.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@gmail.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@gmail.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;
next prev parent reply other threads:[~2010-06-13 20:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-12 10:28 mpd client timeouts (bisected) 2.6.35-rc3 Markus Trippelsdorf
2010-06-12 21:58 ` David Miller
2010-06-13 8:05 ` John Fastabend
2010-06-13 20:36 ` John Fastabend
2010-06-13 20:50 ` Eric Dumazet [this message]
2010-06-14 0:14 ` David Miller
2010-06-13 20:59 ` markus
2010-06-14 0:14 ` David Miller
2010-06-16 10:01 ` Christian Kujau
2010-06-17 15:05 ` Christoph Fritz
2010-06-14 0:13 ` David Miller
2010-06-14 14:13 ` Michael S. Tsirkin
2010-06-17 5:16 ` Shi, Alex
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=1276462246.2448.17.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=alex.shi@intel.com \
--cc=davem@davemloft.net \
--cc=john.r.fastabend@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=netdev@vger.kernel.org \
--cc=tim.c.chen@intel.com \
--cc=yanmin_zhang@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox