From: Marc Dionne <marc.c.dionne@gmail.com>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
netdev <netdev@vger.kernel.org>,
Jeffrey Altman <jaltman@auristor.com>,
Marc Dionne <marc@auristor.com>
Subject: Re: [PATCH] net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets
Date: Mon, 11 Jun 2018 20:09:19 -0300 [thread overview]
Message-ID: <CAB9dFduMTTrpuTETq+hAmy6hRz=EbSi_ba5HzXzazyGcHEayhQ@mail.gmail.com> (raw)
In-Reply-To: <CANP3RGc=hsJ8VmB28ZgN_iBpvC0Ck3_HSctYQMjioZngNKnC7g@mail.gmail.com>
On Mon, Jun 11, 2018 at 7:29 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>> This change is a potential performance regression for us. Our
>> networking code sets up multiple sockets used by multiple threads to
>> listen on the same udp port. For the first socket, the bind is done
>> before setting SO_REUSEPORT so that we can get an error and detect
>> that the port is currently in use by a different process, possibly a
>> previous incarnation of the same application.
>>
>> With this change, the servers end up with a single listener socket and
>> thread, which can have a large impact on performance for a busy
>> server.
>>
>> While we can adjust for the new behaviour going forward, this could be
>> an unpleasant surprise for our customers who get this update when
>> moving to a new kernel version or through a backport to stable
>> kernels, if this is targeted for stable.
>
> Probably you can:
> fd1=socket()
> fd2=socket()
> bind(fd1,port=0)
> setsockopt(fd2,REUSEPORT,1)
> port = getsockname(fd1)
> close(fd1)
> bind(fd2,port)
>
> Although yeah there's a slight chance of a race (ie. 2nd bind failing,
> in which case close() and retry).
This would be a bit different since we want a specific port rather
than a wildcard, but yes, a temporary socket could be bound just to
check if the port is in use and closed afterwards. The problem is
that since fd2 has REUSEPORT set, that second bind might well succeed
if there was a race and the other user of the port also has REUSEPORT
set, as could be the case if it's another instance of the same
application.
Marc
prev parent reply other threads:[~2018-06-11 23:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 17:47 [PATCH] net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on bound sockets Maciej Żenczykowski
2018-06-03 19:54 ` Christoph Paasch
2018-06-04 17:24 ` Eric Dumazet
2018-06-04 21:14 ` David Miller
2018-06-06 23:25 ` Andrei Vagin
2018-06-07 0:25 ` Maciej Żenczykowski
2018-06-07 5:51 ` Andrei Vagin
2018-06-08 10:07 ` Maciej Żenczykowski
2018-06-11 18:35 ` Andrei Vagin
2018-06-11 18:57 ` Andrei Vagin
2018-06-11 21:25 ` [PATCH] " Marc Dionne
2018-06-11 22:29 ` Maciej Żenczykowski
2018-06-11 23:09 ` Marc Dionne [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='CAB9dFduMTTrpuTETq+hAmy6hRz=EbSi_ba5HzXzazyGcHEayhQ@mail.gmail.com' \
--to=marc.c.dionne@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jaltman@auristor.com \
--cc=marc@auristor.com \
--cc=netdev@vger.kernel.org \
--cc=zenczykowski@gmail.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;
as well as URLs for NNTP newsgroup(s).