From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Krzysztof Olędzki" <ole@ans.pl>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: 2.6.34: Problem with UDP traffic on lo + poll(?)
Date: Wed, 08 Sep 2010 06:12:40 +0200 [thread overview]
Message-ID: <1283919160.2634.662.camel@edumazet-laptop> (raw)
In-Reply-To: <4C86B3C6.7040809@ans.pl>
Le mardi 07 septembre 2010 à 23:51 +0200, Krzysztof Olędzki a écrit :
> On 2010-09-07 23:39, Eric Dumazet wrote:
> > Le mardi 07 septembre 2010 à 23:28 +0200, Krzysztof Olędzki a écrit :
> >
> >> With the above patch I'm no longer able to reproduce the problem. Thanks!
> >>
> >> Tested-by: Krzysztof Piotr Oledzki<ole@ans.pl>
> >>
> >
> > Thanks a lot !
> >
> >> BTW: why it takes so long to trigger this bug and it is only possible
> >> over a loopback interface?
> >
> > Its a bit tricky : You need at least 10 sockets linked in a particular
> > hash chain.
> >
> > To check this, you can :
> >
> > cat /proc/net/udp
> >
> > maybe you have many sockets on port 123 or 53 ?
>
> On one affected host I have 3+7 and on the other, also affacted one, I have 3+6:
>
> root@sowa:~# egrep -cw '(53|123):' /proc/net/udp
> 10
> root@sowa:~# egrep -w '(53|123):' /proc/net/udp
> 53: 3582A8C0:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 6084654 2 ffff8800cc012700 0
> 53: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 6084652 2 ffff8800cc010900 0
> 123: D683A8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4911 2 ffff88012de96400 0
> 123: 7B85A8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4910 2 ffff88012de96100 0
> 123: 8982A8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4909 2 ffff88012de95e00 0
> 123: 7B82A8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4908 2 ffff88012de95b00 0
> 123: 3582A8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4907 2 ffff88012de95800 0
> 123: 1F7EA8C0:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4906 2 ffff88012de95500 0
> 123: 0100007F:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4905 2 ffff88012de95200 0
> 123: 00000000:007B 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4899 2 ffff88012de94c00 0
>
> But how 123 is related to 53?
>
I was mentioning 123 or 53, as probable suspects :)
When a socket is created, and connect() called, autobind() chooses a
source port X for this socket.
if ((X % udp_hash_size) == 123), socket is inserted in hash chain number
123.
Bug then triggers, because when a packet is received for this socket, we
find a slot with more than 10 sockets -> Search is done on secondary
chain Z2, where we dont find the socket since its rcv_addr changed after
we inserted it (in chain Y2). Packet is dropped (as seen in netstat -s)
> > And about loopback, I have no idea... I am pretty sure I can trigger the
> > bug with other interfaces.
>
> OK. Probably it is because my other hosts have only a single IP and only
> the problematic ones have both DNS server and multiple IP (many sockets).
>
Yes
prev parent reply other threads:[~2010-09-08 4:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-06 17:11 2.6.34: Problem with UDP traffic on lo + poll(?) Krzysztof Oledzki
2010-09-06 19:42 ` Eric Dumazet
2010-09-06 19:55 ` Krzysztof Olędzki
2010-09-06 20:29 ` Eric Dumazet
2010-09-06 20:44 ` Krzysztof Olędzki
2010-09-06 20:48 ` Krzysztof Olędzki
2010-09-07 15:37 ` Krzysztof Olędzki
2010-09-07 16:36 ` Eric Dumazet
2010-09-07 19:20 ` Krzysztof Olędzki
2010-09-07 19:26 ` Eric Dumazet
2010-09-07 19:59 ` David Miller
2010-09-07 21:35 ` [PATCH] inet: dont set inet_rcv_saddr in connect() Eric Dumazet
2010-09-07 21:52 ` Krzysztof Olędzki
2010-09-08 2:16 ` David Miller
2010-09-08 4:13 ` Eric Dumazet
2010-09-08 2:34 ` Brian Haley
2010-09-08 3:34 ` David Miller
2010-09-08 4:42 ` Eric Dumazet
2010-09-08 5:51 ` David Miller
2010-09-08 4:57 ` Eric Dumazet
2010-09-08 5:36 ` David Miller
2010-09-08 5:52 ` Eric Dumazet
2010-09-08 10:10 ` [PATCH] udp: add rehash on connect() Eric Dumazet
2010-09-08 15:06 ` Krzysztof Olędzki
2010-09-08 15:17 ` Eric Dumazet
2010-09-08 15:29 ` Krzysztof Olędzki
2010-09-08 15:08 ` [PATCH v2] " Eric Dumazet
2010-09-08 16:52 ` Krzysztof Olędzki
2010-09-09 4:39 ` David Miller
2010-09-08 14:27 ` [PATCH] inet: dont set inet_rcv_saddr in connect() Eric Dumazet
2010-09-07 21:28 ` 2.6.34: Problem with UDP traffic on lo + poll(?) Krzysztof Olędzki
2010-09-07 21:39 ` Eric Dumazet
2010-09-07 21:51 ` Krzysztof Olędzki
2010-09-08 4:12 ` Eric Dumazet [this message]
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=1283919160.2634.662.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ole@ans.pl \
/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