Any ideas about how to fix the core issue of tb->fast* being
effectively invalid?
ie. currently any reader of tb->fastreuse(port) which isn't simply
testing for it being >= 0 is basically a bug (-1 is the empty tb case,
so that AFAICT keeps on working).
For example sk_reuseport_match(tb, sk) can
ubuntu-vm systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
>
> Fixes: f396922d862a ("net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on
> bound sockets")
> Signed-off-by: Bart Van Assche
Applied, thanks.
I held off on submitting the reverted patch to -stable, and have now
thus removed it from my -stable queue.
iled to start Avahi mDNS/DNS-SD Stack.
>
> Fixes: f396922d862a ("net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on
> bound sockets")
> Cc: Maciej Żenczykowski
> Cc: Eric Dumazet
> Signed-off-by: Bart Van Assche
> ---
> net/core/sock.c | 15 +-
Jun 12 09:49:24 ubuntu-vm systemd[1]: avahi-daemon.service: Failed with result
'exit-code'.
Jun 12 09:49:24 ubuntu-vm systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
Fixes: f396922d862a ("net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on
bound sockets")
Cc: Mac
On Mon, Jun 11, 2018 at 7:29 PM, Maciej Żenczykowski
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_REUSEPO
> 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 curr
On Sun, Jun 3, 2018 at 2:47 PM, Maciej Żenczykowski
wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far reaching co
On Sun, Jun 03, 2018 at 10:47:05AM -0700, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far
th introduced changes, the tcp_repair mode doesn't affect sk_reuse, so
it is possible to set its value before switching a socket into the
repair mode.
Fixes: f396922d862a ("net: do not allow changing SO_REUSEADDR/SO_REUSEPORT on
bound sockets")
Signed-off-by: Andrei Vagin
---
inclu
I think we probably need to make sk->sk_reuse back into a boolean.
(ie. eliminate SK_FORCE_REUSE)
Then add a new tcp/udp sk->ignore_bind_conflicts boolean setting...
(ie. not just for tcp, but sol_socket) [or perhaps SO_REPAIR,
sk->repair or something]
What I'm not certain of is exactly what sor
On Wed, Jun 06, 2018 at 05:25:51PM -0700, Maciej Żenczykowski wrote:
> Yes, it does, we found this internally last night and been debating
> what to do about it.
>
> Fundamentally what it points out is that prior to this patch CRIU
> could get the host into an inconsistent state.
Yes, I understan
Yes, it does, we found this internally last night and been debating
what to do about it.
Fundamentally what it points out is that prior to this patch CRIU
could get the host into an inconsistent state.
It inserts all the sockets into the hashtables with SO_REUSEADDR set,
and then (potentially) cle
This patch breaks CRIU tests:
= Run zdtm/transition/socket-tcp6 in h =
Start test
./socket-tcp6 --pidfile=socket-tcp6.pid --outfile=socket-tcp6.out
start time for zdtm/transition/socket-tcp6: 0.90
Run criu dump
Run criu restore
=[log]=> dump/zdtm/transition/
From: "Maciej Żenczykowski"
Date: Sun, 3 Jun 2018 10:47:05 -0700
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far r
On 06/03/2018 10:47 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
Reviewed-by: Eric Dumazet
Hello,
On Sun, Jun 3, 2018 at 10:47 AM, Maciej Żenczykowski
wrote:
> From: Maciej Żenczykowski
>
> It is not safe to do so because such sockets are already in the
> hash tables and changing these options can result in invalidating
> the tb->fastreuse(port) caching.
>
> This can have later far re
From: Maciej Żenczykowski
It is not safe to do so because such sockets are already in the
hash tables and changing these options can result in invalidating
the tb->fastreuse(port) caching.
This can have later far reaching consequences wrt. bind conflict checks
which rely on these caches (for opt
17 matches
Mail list logo
