From: Eric Dumazet <eric.dumazet@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: Question regarding expected behavior of two udp sockets with SO_REUSEADDR set
Date: Sat, 20 Nov 2010 05:06:55 +0100 [thread overview]
Message-ID: <1290226015.2756.14.camel@edumazet-laptop> (raw)
In-Reply-To: <20101120004847.GA2590@hmsreliant.think-freely.org>
Le vendredi 19 novembre 2010 à 19:48 -0500, Neil Horman a écrit :
> Hey all-
>
> Got a question regarding expected/desired behavior of $SUBJECT
>
>
> I have a report of a problem with a program that opens two sockets:
>
> The first socket is UDP and binds to 127.0.0.1 on a randomly selected port
>
> The second socket is UDP and calls connect, sending to the first socket
>
> Both sockets are part of the same process and have SO_REUSEADDR set
>
> After the connect the second socket sends a message to the first socket. The
> first socket waits for the message by calling select().
>
> Its observed that occasionally the first socket fails to receive the message,
> which is odd, given that the system is unloaded, and this is the only message
> being sent. A little investigation shows that when this happens, the client and
> the server wind up bound to the same port.
>
> This happens because the second socket calls inet_autobind during the connect
> call, and since both it and the server have SO_REUSEADDR set, it is possible
> that the autobind will select the same port that the first socket is bound to.
> When this happens the sendmsg path can get confused. Specifically, when the skb
> is delivered to the destination socket, the hash lookup might find the wrong
> entry and enqueue the skb to the second socket instead of the first.
>
> Questions:
>
> 1) Is that expected?
>
Is SO_REUSADDR used on both sockets ?
May I ask why SO_REUSEADDR is set in the first place on UDP sockets ?
I use it before a bind() on a given port (non null), but apparently your
program doesnt bind() the 2nd socket before its connect() ?
> 2) If not, what do you think the best way to fix it is?
>
> a) Deny autobinds to the same port when SO_REUSEADDR is set, but allow
> explicity binds to the same port?
>
> b) Deny both autobinds and explicit binds to the same port/addr,
> effectively disablind SO_REUSEADDR with UDP, kind of like with listening TCP
> sockets
>
> c) Add magic to udp_rcv to detect skbs originating from local sockets,
> and _dont_ deliver to the socket it originated from
Why ? Its a valid use case IMHO, even with a single socket.
>
> I'm inclined to say, no this is not expected behavior, and that we should fix it
> with option A, but I'm interested in getting other opinions before I go down any
> particular path.
>
autobind certainly is a problem, we tried to 'fix' it in recent past and
had to revert some patches. We tried to allow more sockets to be used
but we failed.
next prev parent reply other threads:[~2010-11-20 4:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-20 0:48 Question regarding expected behavior of two udp sockets with SO_REUSEADDR set Neil Horman
2010-11-20 4:06 ` Eric Dumazet [this message]
2010-11-20 15:04 ` Neil Horman
2010-11-20 15:38 ` Eric Dumazet
2010-11-20 15:44 ` Eric Dumazet
2010-11-21 0:50 ` Neil Horman
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=1290226015.2756.14.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.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