From: Saikrishna Arcot <firstname.lastname@example.org>
To: David Ahern <email@example.com>,
Paul Menzel <firstname.lastname@example.org>,
Mike Manning <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
"David S. Miller" <firstname.lastname@example.org>
Subject: RE: [EXTERNAL] Re: Change in behavior for bound vs unbound sockets
Date: Thu, 2 Sep 2021 00:16:31 +0000 [thread overview]
Message-ID: <BL0PR2101MB1316DCC9FFC2B0BBA9F66815D9CE9@BL0PR2101MB1316.namprd21.prod.outlook.com> (raw)
>On 8/31/21 7:29 PM, Paul Menzel wrote:
>>> Is the intention of those commits also meant to affect sockets that
>>> are bound to just regular interfaces (and not only VRFs)? If so,
>>> since this change breaks a userspace application, is it possible to
>>> add a config that reverts to the old behavior, where bound sockets
>>> are preferred over unbound sockets?
>> If it breaks user space, the old behavior needs to be restored
>> according to Linux' no regression policy. Let's hope, in the future,
>> there is better testing infrastructure and such issues are noticed earlier.
>5.0 was 2-1/2 years ago.
Does that mean that this should be considered the new behavior? Is it
possible to at least add a sysctl config to use the older behavior for
non-VRF socket bindings?
>Feel free to add tests to tools/testing/selftests/net/fcnal-test.sh to cover any
>missing permutations, including what you believe is the problem here. Both IPv4
>and IPv6 should be added for consistency across protocols.
>nettest.c has a lot of the networking APIs, supports udp, tcp, raw, ...
Let me try to add a test case there. I'm guessing test cases added there
should pass with the current version of the kernel (i.e. should reflect the
next prev parent reply other threads:[~2021-09-02 0:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 23:47 Change in behavior for bound vs unbound sockets Saikrishna Arcot
2021-08-31 10:12 ` Paul Menzel
2021-09-01 2:29 ` David Ahern
2021-09-02 0:16 ` Saikrishna Arcot [this message]
2021-09-02 3:41 ` [EXTERNAL] " David Ahern
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.