Hmm, I certainly like this.
So IMHO this is indeed much better than a sysctl to select a magic
port to ignore during a bind call (previous internal patchset),
although it does use up one more bit per socket (and one more syscall
per connect).
---
Thinking about this some more, I think it might
From: Maciej Żenczykowski m...@google.com
s-local.data is a pointer to a field of a non-NULL struct, and hence
cannot be NULL, thus comparing it to 0 is always false, and thus the
return is always false.
Presumably this was meant to be a check whether s-local.data[0] (which
I believe stores
From: Maciej Żenczykowski m...@google.com
The initializers are simply not needed.
These if-blocks are outright dead code, because '0 unsigned' is always
false, so only else clause triggers and regardless of which clause triggers
it only updates 'ind' which is later unconditionally written
What are you trying to do?
The intent of the patch is to be able to terminate connections from
outside the machine that are reaching the machine (perhaps delivered
inside a tunnel or via some other mechanism: static arp entries,
routing via the machine, etc), that the kernel wouldn't normally
> Once it figures out which gso_inner_segment to use, it calls
> __skb_udp_tunnel_segment with it, which then does some curious header
> calculations on various lengths (that I need to read carefully), and
> then proceeds to split the segments using our gso_inner_segment
> function of choice, and
> I suppose this is about UFO.
>
> Specifically -- let's say I have a list of 500 skbs, which have their
> data in place but don't yet have an IP or UDP header etc. I want to
> send out these out using udp_tunnel_xmit_skb. Right now, if I just
> send them all out, one after another, they don't
> What I was thinking about is this: My driver receives a super-packet.
> By calling skb_gso_segment(), I'm given a list of equal sized packets
> (of gso_size each), except for the last one which is either the same
> size or smaller than the rest. Let's say calling skb_gso_segment()
> gives me a
> I would like to have a "bind-to-subnet" semantic with IPv6.
Ah, this is something that I have reason to suspect may indeed be
broken for IPv6.
A coworker did some one-off testing on this a few months back, and
didn't get it to trivially work.
We didn't debug it, nor try to figure out what (if
I don't know what the right fix is...
However, speaking as an end user with laptops on wifi and/or home
gateways on dialup connections where the IP address occasionally (or
constantly) changes, I find it very frustrating that by default as IP
addresses get removed from interfaces all the related
I'd tend to agree that reset or abort would be preferable to destroy.
After all... the socket doesn't actually go away.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
> What I object to is userspace making reachability decisions, not
> whether SOCK_DESTROY closes the socket in one way or the other.
Privileged userspace can already make these decisions today, whether
it is by killing processes with open sockets, or by turning interfaces
up and down or by
>> In this case, userspace knows that that app's connections are now
>> unusable because it configured an iptables rule to block them. The
>> kernel doesn't really know until it the time comes to send a packet,
>> and maybe not even then.
>
> Netfilter could perform signalling on skb->sk when it
> Ack. With emphasis of *application*. :)
The problem with application anything is that changing apps is
outright impossible.
There are far too many of them written by far too many people.
And until you fix them all (which is infeasible) and roll those
changes out (unlikely) users will continue
> Having comments like "look, just implement application keepalives" is
> not going to work [1][2]. This is terrible, and show lack of
> understanding of the problem. We are not dealing with DC communications
> here. (I wish !)
There's a 3rd reason: keepalives (tcp or application) are actually
> No, I mean something that kills connections where previously this did
> not happen. The fact that this is done at the process level does not
> justify that it is a right to at do connections. Besides, if you
> really intend to do this then provide a privileged process a means to
> close *any*
Ack. Feel free to add:
Reported-by: Maciej Żenczykowski <m...@google.com>
(via Eric Dumazet)
If needed:
Signed-off-by: Maciej Żenczykowski <m...@google.com>
If needed:
Signed-off-by: Maciej Żenczykowski <m...@google.com>
If needed:
Signed-off-by: Maciej Żenczykowski <m...@google.com>
If needed:
Signed-off-by: Maciej Żenczykowski <m...@google.com>
From: Maciej Żenczykowski <m...@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addr
From: Maciej Żenczykowski <m...@google.com>
This allows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to -1 meaning an unlimited number of retransmits.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 ++
1 file changed, 6 inse
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
Accessible via:
/proc/sys/net/ipv6/conf/*/router_solicitation_max_interval
For now we default it to the same value as the normal interval.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/linux/ipv6.h | 1 +
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitations
/proc/sys/net/ipv6/conf/default/router_solicitations
from 3 to unlimited.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Signed-off-by: Maciej Żenczykow
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitation_max_interval
/proc/sys/net/ipv6/conf/default/router_solicitation_max_interval
from 4 seconds to 1 hour.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Sign
> Given that some of this patch checks for == -1, and some of it checks
> for != 0... is it possible that setting the value to something
> unexpected like -3 will cause any issues to the stack? (Other than
> just rendering IPv6 unusable on this interface, which seems like a
> given.)
You
From: Maciej Żenczykowski <m...@google.com>
This disallows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to values below -1.
-1 continues to mean an unlimited number of retransmits.
Note: this depends on 'ipv6 addrconf: remove addrconf_sysctl_hop_limit()'
Signed-off-by:
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitations
/proc/sys/net/ipv6/conf/default/router_solicitations
from 3 to unlimited.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Signed-off-by: Maciej Żenczykow
> Good point. Using ms should actually be easy, instead of
> proc_dointvec_jiffies you can use proc_dointvec_ms_jiffies.
Yes, I'm aware of this, but 'proc_dointvec_ms_jiffies' seems to be a
bit of a hack, and especially for large settings like this exporting
them to userspace in units of ms
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitation_max_interval
/proc/sys/net/ipv6/conf/default/router_solicitation_max_interval
from 4 seconds to 1 hour.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Sign
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
From: Maciej Żenczykowski <m...@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addr
Hi,
This patch series implements RFC7559 style backoff of IPv6 router
solicitation requests.
Patches 1 and 2 are minor cleanup and stand on their own.
Patch 3 allows a (potentially) infinite number of RS'es to be sent
when the rtr_solicits sysctl is set to -1 (this depends on patch 1).
Patch 4
From: Maciej Żenczykowski <m...@google.com>
Accessible via:
/proc/sys/net/ipv6/conf/*/router_solicitation_max_interval
For now we default it to the same value as the normal interval.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/linux/ipv6.h | 1 +
From: Maciej Żenczykowski <m...@google.com>
This allows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to -1 meaning an unlimited number of retransmits.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 ++
1 file changed, 6 inse
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
This is an effective no-op in terms of user observable behaviour.
By preventing the overwrite of non-null extra1/extra2 fields
in addrconf_sysctl() we can enable the use of proc_dointvec_minmax().
This allows us to eliminate the constant min/
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
We allow setting /proc/sys/net/ipv6/conf/*/router_solicitations
to a negative value m
I don't think you actually need the backslashes since this ain't in a
MACRO definition context.
I'm not sure what line you're referring to.
There are *no* outright jiffies or msecs in this patch, with the
exception of the (3600*HZ) line which is already obvious enough.
The 90 21 190 100 constants are not jiffies nor
miliseconds, they're simply numbers, such that
It is if you don't want build warnings about discarding 'const' qualifier.
From: Maciej Żenczykowski <m...@google.com>
This disallows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to values below -1.
-1 continues to mean an unlimited number of retransmits.
Note: this depends on 'ipv6 addrconf: remove addrconf_sysctl_hop_limit()'
Signed-off-by:
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
From: Maciej Żenczykowski <m...@google.com>
Accessible via:
/proc/sys/net/ipv6/conf/*/router_solicitation_max_interval
For now we default it to the same value as the normal interval.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/linux/ipv6.h | 1 +
From: Maciej Żenczykowski <m...@google.com>
This allows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to -1 meaning an unlimited number of retransmits.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 ++
1 file changed, 6 inse
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitations
/proc/sys/net/ipv6/conf/default/router_solicitations
from 3 to unlimited.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Signed-off-by: Maciej Żenczykow
From: Maciej Żenczykowski <m...@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addr
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitation_max_interval
/proc/sys/net/ipv6/conf/default/router_solicitation_max_interval
from 4 seconds to 1 hour.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Sign
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitations
/proc/sys/net/ipv6/conf/default/router_solicitations
from 3 to unlimited.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Signed-off-by: Maciej Żenczykow
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
Accessible via:
/proc/sys/net/ipv6/conf/*/router_solicitation_max_interval
For now we default it to the same value as the normal interval.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/linux/ipv6.h | 1 +
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitation_max_interval
/proc/sys/net/ipv6/conf/default/router_solicitation_max_interval
from 4 seconds to 1 hour.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Sign
From: Maciej Żenczykowski <m...@google.com>
This allows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to -1 meaning an unlimited number of retransmits.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 ++
1 file changed, 6 inse
From: Maciej Żenczykowski <m...@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addr
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
Hi,
This patch series implements RFC7559 style backoff of IPv6 router
solicitation requests.
Patches 1 and 2 are minor cleanup and stand on their own.
Patch 3 allows a (potentially) infinite number of RS'es to be sent
when the rtr_solicits sysctl is set to -1 (this depends on patch 1).
Patch 4
From: Maciej Żenczykowski <m...@google.com>
Accessible via:
/proc/sys/net/ipv6/conf/*/router_solicitation_max_interval
For now we default it to the same value as the normal interval.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/linux/ipv6.h | 1 +
From: Maciej Żenczykowski <m...@google.com>
replace with extra1/2 magic
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addr
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitation_max_interval
/proc/sys/net/ipv6/conf/default/router_solicitation_max_interval
from 4 seconds to 1 hour.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Sign
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
From: Maciej Żenczykowski <m...@google.com>
This allows setting /proc/sys/net/ipv6/conf/*/router_solicitations
to -1 meaning an unlimited number of retransmits.
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 ++
1 file changed, 6 inse
Hi,
This patch series implements RFC7559 style backoff of IPv6 router
solicitation requests.
Patches 1 and 2 are minor cleanup and stand on their own.
Patch 3 allows a (potentially) infinite number of RS'es to be sent
when the rtr_solicits sysctl is set to -1 (this depends on patch 1).
Patch 4
From: Maciej Żenczykowski <m...@google.com>
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
net/ipv6/addrconf.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2f1f5d439788..11fa1a5564d4 100644
--
From: Maciej Żenczykowski <m...@google.com>
This changes:
/proc/sys/net/ipv6/conf/all/router_solicitations
/proc/sys/net/ipv6/conf/default/router_solicitations
from 3 to unlimited.
This is the https://tools.ietf.org/html/rfc7559 recommended default.
Signed-off-by: Maciej Żenczykow
Ok, so that seems to have all sorts of __divdi3 or __aeabi_ldivmod
undefined errors on 32-bit platforms (ie. arm/m68k/i386).
From: Maciej Żenczykowski <m...@google.com>
This implements:
https://tools.ietf.org/html/rfc7559
Backoff is performed according to RFC3315 section 14:
https://tools.ietf.org/html/rfc3315#section-14
Signed-off-by: Maciej Żenczykowski <m...@google.com>
---
include/net/if_inet6.h
>> +static int one = 1;
>> +static int two_five_five = 255;
>
> Should these be const as well?
It would be nice, but you actually get compile time warnings if you do that.
> Is seconds granular enough?
The only reason why one would ever want to go into fractions of
seconds would be some sort of unittesting with very low delays.
In any normal environment the max is going to be tens if not hundreds
or thousands of seconds.
Also note that the delay and interval (ie.
> Please just use do_div here and go back to the first version of the
> patch. Variable names could be more aligned with the RFC maybe?
So I tried:
static inline s32 rfc3315_s14_backoff_init(s32 irt)
{
/* multiply 'initial retransmission time' by 0.9 .. 1.1 */
u64 tmp = (90 +
That wouldn't really simplify much.
This change currently has 5 lines.
3 of those would be needed anyway if we were to define anything < 0 to
mean infinite.
Yes, you could get rid of the two lines with minus_one in them, but
this way we can also use -2 to mean something else in the future if we
but:
Acked-by: Maciej Żenczykowski
> Please remove the const qualifier and the casts to be consistent
> with how we handle this elsewhere.
>
> Thanks.
I can of course trivially make that change.
But:
(on net-next/master)
git grep 'extra[12].*=.*\(void *[*]\)'
currently finds 45 matches, and this patch adds a 46th.
In
Acked-by: Maciej Żenczykowski <m...@google.com>
Acked-by: Maciej Żenczykowski <m...@google.com>
Just FYI:
I'm tangentially aware of internal Google code that:
- expects a bonding device running HTB with non-zero txqueuelen
- wants to remove HTB and get a noqueue interface (the normal default
for bonding)
The code currently removes HTB, which gets us to mq, sets txqueuelen
to 0, adds a
From: Maciej Żenczykowski <m...@google.com>
Routes can specify an mtu explicitly or inherit the mtu from
the underlying device - this inheritance is implemented in
dst->ops->mtu handlers ip6_mtu() and ip6_blackhole_mtu().
Currently changing the mtu of a device adds mtu explicitly
to
Acked-by: Maciej Żenczykowski <m...@google.com>
One thing to consider...
Just because the compiler could be in the kernel, doesn't mean it has to be.
One could envision a hotplug/modprobe like helper program that the
kernel executes
when it wants to translate from one encoding (say p4) to another (say [e]bpf).
This keeps complexity
> Sorry for jumping into the middle and the delay (plumbers this week). My
> question would be, if the main target is for p4 *offloading* anyway, who
> would use this sw fallback path? Mostly for testing purposes?
>
> I'm not sure about compilerB here and the complexity that needs to be
> pushed
eive both ICMP
> and other errors cannot rely on this legacy behavior, as other
> errors do not set sk_err in the first place.
>
> Fixes: f5f99309fa74 (sock: do not set sk_err in sock_dequeue_err_skb)
> Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com>
> Signed-off-by: Willem de Bruijn <will...@google.com>
Acked-by: Maciej Żenczykowski <m...@google.com>
> In what case is the current behavior a problem (my guess would
> be something related to LLDP)?
LLDP is indeed the case we're trying to solve here.
Listen on one socket and get LLDP for all interfaces in the system.
> What if, e.g., the bond is a bridge
> port, will STP frames no
So this is clearly an improvement over the current state of things.
However, I think there is still a very slight race condition in the
error case, since I imagine udp early demux might find the socket
while ip6_datagram_dst_update() is running.
It's possible that inet_dport assignment could
From: Maciej Żenczykowski <m...@google.com>
This function is unused, and furthermore it is buggy since it suffers
from the same issue that requires IP6_ECN_set_ce() to take a pointer
to the skb so that it may (in case of CHECKSUM_COMPLETE) update skb->csum
Instead of fixing it, l
From: Maciej Żenczykowski <m...@google.com>
So far we've been relying on sockopt(SOL_IP, IP_FREEBIND) being usable
even on IPv6 sockets.
However, it turns out it is perfectly reasonable to want to set freebind
on an AF_INET6 SOCK_RAW socket - but there is no way to set any SOL_IP
socket
Acked-by: Maciej Żenczykowski <m...@google.com>
>> Should we consider rolling back the patch that caused this?
>> "accept_dad = 1" is the proper IETF-expected default behaviour.
>>
>> Alternatively, if we really want to make all, default, and ifname
>> useful perhaps we need to investigate a tristate option (for currently
>> boolean values, at
From: Maciej Żenczykowski <m...@google.com>
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() ->
From: Maciej Żenczykowski <m...@google.com>
Add a per-device sysctl to specify the default traffic class to use for
kernel originated IPv6 Neighbour Discovery packets.
Currently this includes:
- Router Solicitation (ICMPv6 type 133)
ndisc_send_rs() -> ndisc_send_skb() ->
> 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
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
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
> #define SK_NO_REUSE0
> #define SK_CAN_REUSE 1
since it's a boolean now these should go away too I believe.
should there simply/also be a separate privileged socket option to
set/get force reuse?
> Hi Andrey
>
> This commit was reverted, do we still need this patch ?
I think it still makes things easier to understand...
From: Maciej Żenczykowski
This changes the /proc/sys/net/ipv4/tcp_tw_reuse from a boolean
to an integer.
It now takes the values 0, 1 and 2, where 0 and 1 behave as before,
while 2 enables timewait socket reuse only for sockets that we can
prove are loopback connections:
ie. bound to 'lo
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 cac
1 - 100 of 143 matches
Mail list logo
