I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr socket successfully opens on an
existing tb. The root cause is I reversed an if statement which caused us to
set the tb as if there were no owners on the socket if there were, which
obviously is not correct.
Dave I have follow up patches that will add a selftest for this case and I ran
the other reuseport related tests as well. These need to go in pretty quickly
as it breaks kvm, I've marked them for stable. Sorry for the regression,
Josef
From: Josef Bacik <redacted>
In ipv6_rcv_saddr_equal() we need to use inet6_rcv_saddr(sk) for the
ipv6 compare with the fast socket information to make sure we're doing
the proper comparisons.
Cc: stable@vger.kernel.org
Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson <redacted>
Signed-off-by: Josef Bacik <redacted>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Josef Bacik <redacted>
When doing my reuseport rework I screwed up and changed a
if (hlist_empty(&tb->owners))
to
if (!hlist_empty(&tb->owners))
This is obviously bad as all of the reuseport/reuse logic was reversed,
which caused weird problems like allowing an ipv4 bind conflict if we
opened an ipv4 only socket on a port followed by an ipv6 only socket on
the same port.
Cc: stable@vger.kernel.org
Fixes: b9470c27607b ("inet: kill smallest_size and smallest_port")
Reported-by: Cole Robinson <redacted>
Signed-off-by: Josef Bacik <redacted>
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Josef Bacik <redacted>
We need to set the tb->fast_sk_family properly so we can use the proper
comparison function for all subsequent reuseport bind requests.
Cc: stable@vger.kernel.org
Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson <redacted>
Signed-off-by: Josef Bacik <redacted>
---
net/ipv4/inet_connection_sock.c | 2 ++
1 file changed, 2 insertions(+)
On 09/18/2017 12:28 PM, josef@toxicpanda.com wrote:
I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr socket successfully opens on an
existing tb. The root cause is I reversed an if statement which caused us to
set the tb as if there were no owners on the socket if there were, which
obviously is not correct.
Dave I have follow up patches that will add a selftest for this case and I ran
the other reuseport related tests as well. These need to go in pretty quickly
as it breaks kvm, I've marked them for stable. Sorry for the regression,
To clarify, it doesn't really break KVM specifically, but it breaks a
port collision detection idiom that libvirt depends on to successfully
launch qemu/xen/... VMs in certain cases.
Thanks,
Cole
I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr socket successfully opens on an
existing tb. The root cause is I reversed an if statement which caused us to
set the tb as if there were no owners on the socket if there were, which
obviously is not correct.
Dave I have follow up patches that will add a selftest for this case and I ran
the other reuseport related tests as well. These need to go in pretty quickly
as it breaks kvm, I've marked them for stable. Sorry for the regression,
First, please fix your "From: " field so that it actually has your full
name rather than just your email address. This matter when I apply
your patches.
Second, remove the stable CC:. For networking changes, you simply ask
me to queue the changes up for -stable.
Thanks.
I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr socket successfully opens on an
existing tb. The root cause is I reversed an if statement which caused us to
set the tb as if there were no owners on the socket if there were, which
obviously is not correct.
Dave I have follow up patches that will add a selftest for this case and I ran
the other reuseport related tests as well. These need to go in pretty quickly
as it breaks kvm, I've marked them for stable. Sorry for the regression,
First, please fix your "From: " field so that it actually has your full
name rather than just your email address. This matter when I apply
your patches.
Second, remove the stable CC:. For networking changes, you simply ask
me to queue the changes up for -stable.
Sorry Dave, I've fixed my git email settings and I droped the stable cc and sent
a new round. Didn't see this until just now, my bad.
Josef