* Re: Regression Issue
[not found] <DM4PR11MB55183E4B87078E0F496386029A719@DM4PR11MB5518.namprd11.prod.outlook.com>
@ 2023-05-08 7:40 ` Greg KH
2023-05-08 7:52 ` Rai, Anjali
2023-05-08 7:57 ` Linux regression tracking (Thorsten Leemhuis)
0 siblings, 2 replies; 7+ messages in thread
From: Greg KH @ 2023-05-08 7:40 UTC (permalink / raw)
To: Rai, Anjali
Cc: regressions@lists.linux.dev, stable@vger.kernel.org,
Gandhi, Jinen, Qin, Kailun
On Mon, May 08, 2023 at 07:33:58AM +0000, Rai, Anjali wrote:
> Hi
>
> 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/28044fc1d4953b07acec0da4d2fc4784c57ea6fb
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?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Regression Issue
2023-05-08 7:40 ` Regression Issue Greg KH
@ 2023-05-08 7:52 ` Rai, Anjali
2023-05-08 8:27 ` Rai, Anjali
2023-05-08 7:57 ` Linux regression tracking (Thorsten Leemhuis)
1 sibling, 1 reply; 7+ messages in thread
From: Rai, Anjali @ 2023-05-08 7:52 UTC (permalink / raw)
To: Greg KH, joannelkoong@gmail.com, kuba@kernel.org
Cc: regressions@lists.linux.dev, stable@vger.kernel.org,
Gandhi, Jinen, Qin, Kailun
Adding the authors of commit.
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.
-----Original Message-----
From: Greg KH <gregkh@linuxfoundation.org>
Sent: Monday, May 8, 2023 1:11 PM
To: Rai, Anjali <anjali.rai@intel.com>
Cc: regressions@lists.linux.dev; stable@vger.kernel.org; Gandhi, Jinen <jinen.gandhi@intel.com>; Qin, Kailun <kailun.qin@intel.com>
Subject: Re: Regression Issue
On Mon, May 08, 2023 at 07:33:58AM +0000, Rai, Anjali wrote:
> Hi
>
> 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?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Regression Issue
2023-05-08 7:40 ` Regression Issue Greg KH
2023-05-08 7:52 ` Rai, Anjali
@ 2023-05-08 7:57 ` Linux regression tracking (Thorsten Leemhuis)
1 sibling, 0 replies; 7+ messages in thread
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-05-08 7:57 UTC (permalink / raw)
To: Rai, Anjali
Cc: regressions@lists.linux.dev, stable@vger.kernel.org,
Gandhi, Jinen, Qin, Kailun, Greg KH
On 08.05.23 09:40, Greg KH 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/28044fc1d4953b07acec0da4d2fc4784c57ea6fb
>
> 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?
FWIW: that commit you mentioned above indeed caused a regression in a
test, but the issue was fixed before 6.2 was released -- or at least it
is supposed to. For details see:
https://lore.kernel.org/all/6b971a4e-c7d8-411e-1f92-fda29b5b2fb9@kernel.org/
Ciao, Thorsten
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Regression Issue
2023-05-08 7:52 ` Rai, Anjali
@ 2023-05-08 8:27 ` Rai, Anjali
2023-05-08 19:31 ` Jakub Kicinski
0 siblings, 1 reply; 7+ messages in thread
From: Rai, Anjali @ 2023-05-08 8:27 UTC (permalink / raw)
To: Greg KH, joannelkoong@gmail.com, kuba@kernel.org
Cc: regressions@lists.linux.dev, stable@vger.kernel.org,
Gandhi, Jinen, Qin, Kailun
Ciao,
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"
-----Original Message-----
From: Rai, Anjali
Sent: Monday, May 8, 2023 1:22 PM
To: Greg KH <gregkh@linuxfoundation.org>; joannelkoong@gmail.com; kuba@kernel.org
Cc: regressions@lists.linux.dev; stable@vger.kernel.org; Gandhi, Jinen <jinen.gandhi@intel.com>; Qin, Kailun <kailun.qin@intel.com>
Subject: RE: Regression Issue
Adding the authors of commit.
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.
-----Original Message-----
From: Greg KH <gregkh@linuxfoundation.org>
Sent: Monday, May 8, 2023 1:11 PM
To: Rai, Anjali <anjali.rai@intel.com>
Cc: regressions@lists.linux.dev; stable@vger.kernel.org; Gandhi, Jinen <jinen.gandhi@intel.com>; Qin, Kailun <kailun.qin@intel.com>
Subject: Re: Regression Issue
On Mon, May 08, 2023 at 07:33:58AM +0000, Rai, Anjali wrote:
> Hi
>
> 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?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Regression Issue
2023-05-08 8:27 ` Rai, Anjali
@ 2023-05-08 19:31 ` Jakub Kicinski
2023-05-08 19:44 ` Kuniyuki Iwashima
0 siblings, 1 reply; 7+ messages in thread
From: Jakub Kicinski @ 2023-05-08 19:31 UTC (permalink / raw)
To: Rai, Anjali, Kuniyuki Iwashima
Cc: Greg KH, joannelkoong@gmail.com, regressions@lists.linux.dev,
stable@vger.kernel.org, Gandhi, Jinen, Qin, Kailun,
netdev@vger.kernel.org
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Regression Issue
2023-05-08 19:31 ` Jakub Kicinski
@ 2023-05-08 19:44 ` Kuniyuki Iwashima
2023-05-09 5:46 ` Rai, Anjali
0 siblings, 1 reply; 7+ messages in thread
From: Kuniyuki Iwashima @ 2023-05-08 19:44 UTC (permalink / raw)
To: kuba, anjali.rai
Cc: gregkh, jinen.gandhi, joannelkoong, kailun.qin, kuniyu, netdev,
regressions, stable
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Regression Issue
2023-05-08 19:44 ` Kuniyuki Iwashima
@ 2023-05-09 5:46 ` Rai, Anjali
0 siblings, 0 replies; 7+ messages in thread
From: Rai, Anjali @ 2023-05-09 5:46 UTC (permalink / raw)
To: Kuniyuki Iwashima, kuba@kernel.org
Cc: gregkh@linuxfoundation.org, Gandhi, Jinen, joannelkoong@gmail.com,
Qin, Kailun, netdev@vger.kernel.org, regressions@lists.linux.dev,
stable@vger.kernel.org
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-05-09 5:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <DM4PR11MB55183E4B87078E0F496386029A719@DM4PR11MB5518.namprd11.prod.outlook.com>
2023-05-08 7:40 ` Regression Issue Greg KH
2023-05-08 7:52 ` Rai, Anjali
2023-05-08 8:27 ` Rai, Anjali
2023-05-08 19:31 ` Jakub Kicinski
2023-05-08 19:44 ` Kuniyuki Iwashima
2023-05-09 5:46 ` Rai, Anjali
2023-05-08 7:57 ` Linux regression tracking (Thorsten Leemhuis)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox