Re: Regression Issue

Re: Regression Issue

[Jakub Kicinski]

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?

Re: Regression Issue

[Kuniyuki Iwashima]

From: Jakub Kicinski <kuba@kernel.org>
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@redhat.com/ 
[1]: https://lore.kernel.org/netdev/20230312031904.4674-2-kuniyu@amazon.com/
[2]: https://lore.kernel.org/stable/?q=tcp%3A+Fix+bind%28%29+conflict+check+for+dual-stack+wildcard+address.

RE: Regression Issue

[Rai, Anjali]

I updated the kernel to v6.2.8 and the test runs fine.

Thank you for the help

-----Original Message-----
From: Kuniyuki Iwashima <kuniyu@amazon.com> 
Sent: Tuesday, May 9, 2023 1:14 AM
To: kuba@kernel.org; Rai, Anjali <anjali.rai@intel.com>
Cc: gregkh@linuxfoundation.org; Gandhi, Jinen <jinen.gandhi@intel.com>; joannelkoong@gmail.com; Qin, Kailun <kailun.qin@intel.com>; kuniyu@amazon.com; netdev@vger.kernel.org; regressions@lists.linux.dev; stable@vger.kernel.org
Subject: Re: Regression Issue

From: Jakub Kicinski <kuba@kernel.org>
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/28044fc1d4953b07acec0da
> >>> > 4d2fc4
> >>> > 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@redhat.com/
[1]: https://lore.kernel.org/netdev/20230312031904.4674-2-kuniyu@amazon.com/
[2]: https://lore.kernel.org/stable/?q=tcp%3A+Fix+bind%28%29+conflict+check+for+dual-stack+wildcard+address.