From: Jakub Kicinski <kuba@xxxxxxxxxx> Date: Mon, 8 May 2023 12:31:38 -0700 > On Mon, 8 May 2023 08:27:49 +0000 Rai, Anjali wrote: > > On Mon, May 08, 2023 at 07:33:58AM +0000, Rai, Anjali wrote: > >>> > We have one test which test the functionality of "using the same > >>> > loopback address and port for both IPV6 and IPV4", The test should > >>> > result in EADDRINUSE for binding IPv4 to same port, but it was > >>> > successful > >>> > > >>> > Test Description: > >>> > The test creates sockets for both IPv4 and IPv6, and forces IPV6 to > >>> > listen for both IPV4 and IPV6 connections; this in turn makes binding > >>> > another (IPV4) socket on the same port meaningless and results in > >>> > -EADDRINUSE > >>> > > >>> > Our systems had Kernel v6.0.9 and the test was successfully executing, we recently upgraded our systems to v6.2, and we saw this as a failure. The systems which are not upgraded, there it is still passing. > >>> > > >>> > We don't exactly at which point this test broke, but our assumption is > >>> > https://github.com/torvalds/linux/commit/28044fc1d4953b07acec0da4d2fc4 > >>> > 784c57ea6fb > >>> > >>> Is there a specific reason you did not add cc: for the authors of that commit? > >>> > >>> > Can you please check on your end whether this is an actual regression of a feature request. > >>> > >>> If you revert that commit, does it resolve the issue? Have you worked with the Intel networking developers to help debug this further? > > > > I am part of Gramine OpenSource Project, I don't know someone from > > > Intel Networking developers team, if you know someone, please feel > > > free to add them. > > > > > > Building completely linux source code and trying with different > > > commits, I will not be able to do it today, I can check that may be > > > tomorrow or day after. > > > > The C code was passing earlier, and output was " test completed > > successfully" but now with v6.2 it is failing and returning > > "bind(ipv4) was successful even though there is no IPV6_V6ONLY on > > same port\n" > > Adding the mailing list and the experts. Cleaning up the quoting, > please don't top post going forward. > > Kuniyuki, have we seen this before? Yes, we had the same report [0] and fixed with this patch [1], and it seems to be backported to v6.1.21 and v6.2.8, not v6.0.y (EOL). [0]: https://lore.kernel.org/netdev/e21bf153-80b0-9ec0-15ba-e04a4ad42c34@xxxxxxxxxx/ [1]: https://lore.kernel.org/netdev/20230312031904.4674-2-kuniyu@xxxxxxxxxx/ [2]: https://lore.kernel.org/stable/?q=tcp%3A+Fix+bind%28%29+conflict+check+for+dual-stack+wildcard+address.
