* [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: longer timeout
2025-11-12 9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
@ 2025-11-12 9:45 ` Matthieu Baerts (NGI0)
2025-11-12 9:45 ` [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-11-12 9:45 UTC (permalink / raw)
To: MPTCP Upstream; +Cc: Matthieu Baerts (NGI0)
In rare cases, when the test environment is very slow, some endpoints
tests can fail because some expected events have not been seen.
Because the tests are expecting a long on-going connection, and they are
not waiting for the end of the transfer, it is fine to have a longer
timeout, and even go over the default one. This connection will be
killed at the end, after the verifications: increasing the timeout
doesn't change anything, apart from avoiding it to end before the end of
the verifications.
To play it safe, all endpoints tests not waiting for the end of the
transfer are now having a longer timeout: 2 minutes.
The Fixes commit was making the connection longer, but still, the
default timeout would have stopped it after 1 minute, which might not be
enough in very slow environments.
Fixes: 6457595db987 ("selftests: mptcp: join: endpoints: longer transfer")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
tools/testing/selftests/net/mptcp/mptcp_join.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 41ce0eeed72c..b058f78ea0bd 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -4090,7 +4090,7 @@ endpoint_tests()
pm_nl_set_limits $ns1 2 2
pm_nl_set_limits $ns2 2 2
pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
- { test_linkfail=128 speed=slow \
+ { timeout_test=120 test_linkfail=128 speed=slow \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
@@ -4117,7 +4117,7 @@ endpoint_tests()
pm_nl_set_limits $ns2 0 3
pm_nl_add_endpoint $ns2 10.0.1.2 id 1 dev ns2eth1 flags subflow
pm_nl_add_endpoint $ns2 10.0.2.2 id 2 dev ns2eth2 flags subflow
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
@@ -4195,7 +4195,7 @@ endpoint_tests()
# broadcast IP: no packet for this address will be received on ns1
pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal
pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
@@ -4275,7 +4275,7 @@ endpoint_tests()
# broadcast IP: no packet for this address will be received on ns1
pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal
pm_nl_add_endpoint $ns2 10.0.3.2 id 3 flags subflow
- { test_linkfail=128 speed=20 \
+ { timeout_test=120 test_linkfail=128 speed=20 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
--
2.51.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: longer timeout
2025-11-12 9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
2025-11-12 9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
@ 2025-11-12 9:45 ` Matthieu Baerts (NGI0)
2025-11-12 11:13 ` [PATCH mptcp-net 0/2] selftests: mptcp: join: " MPTCP CI
2025-11-17 11:08 ` Matthieu Baerts
3 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-11-12 9:45 UTC (permalink / raw)
To: MPTCP Upstream; +Cc: Matthieu Baerts (NGI0)
In rare cases, when the test environment is very slow, some userspace
tests can fail because some expected events have not been seen.
Because the tests are expecting a long on-going connection, and they are
not waiting for the end of the transfer, it is fine to have a longer
timeout, and even go over the default one. This connection will be
killed at the end, after the verifications: increasing the timeout
doesn't change anything, apart from avoiding it to end before the end of
the verifications.
To play it safe, all userspace tests not waiting for the end of the
transfer are now having a longer timeout: 2 minutes.
The Fixes commit was making the connection longer, but still, the
default timeout would have stopped it after 1 minute, which might not be
enough in very slow environments.
Fixes: 290493078b96 ("selftests: mptcp: join: userspace: longer transfer")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
tools/testing/selftests/net/mptcp/mptcp_join.sh | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index b058f78ea0bd..541c2676c79e 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -3953,7 +3953,7 @@ userspace_tests()
continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
set_userspace_pm $ns1
pm_nl_set_limits $ns2 2 2
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
wait_mpj $ns1
@@ -3986,7 +3986,7 @@ userspace_tests()
continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
set_userspace_pm $ns2
pm_nl_set_limits $ns1 0 1
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
wait_mpj $ns2
@@ -4014,7 +4014,7 @@ userspace_tests()
continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
set_userspace_pm $ns2
pm_nl_set_limits $ns1 0 1
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
wait_mpj $ns2
@@ -4035,7 +4035,7 @@ userspace_tests()
continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
set_userspace_pm $ns2
pm_nl_set_limits $ns1 0 1
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
wait_mpj $ns2
@@ -4059,7 +4059,7 @@ userspace_tests()
continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
set_userspace_pm $ns1
pm_nl_set_limits $ns2 1 1
- { test_linkfail=128 speed=5 \
+ { timeout_test=120 test_linkfail=128 speed=5 \
run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
local tests_pid=$!
wait_mpj $ns1
--
2.51.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
2025-11-12 9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
2025-11-12 9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
2025-11-12 9:45 ` [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
@ 2025-11-12 11:13 ` MPTCP CI
2025-11-17 11:08 ` Matthieu Baerts
3 siblings, 0 replies; 8+ messages in thread
From: MPTCP CI @ 2025-11-12 11:13 UTC (permalink / raw)
To: Matthieu Baerts; +Cc: mptcp
Hi Matthieu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): selftest_diag 🔴
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19293439106
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/fcb8a7e51251
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1022413
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
2025-11-12 9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
` (2 preceding siblings ...)
2025-11-12 11:13 ` [PATCH mptcp-net 0/2] selftests: mptcp: join: " MPTCP CI
@ 2025-11-17 11:08 ` Matthieu Baerts
2025-11-17 11:26 ` Matthieu Baerts
2025-11-18 8:43 ` Geliang Tang
3 siblings, 2 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-17 11:08 UTC (permalink / raw)
To: MPTCP Linux
Hello,
On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
> A previous attempt was helping, but not enough as the background
> connections were still stopped after the timeout. That's what the MPTCP
> CI recently reported with the "delete and re-add" subtest taking a bit
> more than one minute in a debug environment.
>
> To play it safe, and because increasing the timeout for the background
> connections doesn't change anything to the end result (the transfer is
> not checked in this case), all subtests with a background connection not
> waiting for it to end now have a longer timeout.
I hope it is OK if I apply these patches now: they are simple, linked to
recent patches, and we still have quite a few patches in the queue.
I'm planning to send them with other patches we have in the queue for
net ideally today.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
2025-11-17 11:08 ` Matthieu Baerts
@ 2025-11-17 11:26 ` Matthieu Baerts
2025-11-18 8:43 ` Geliang Tang
1 sibling, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-17 11:26 UTC (permalink / raw)
To: MPTCP Linux
On 17/11/2025 12:08, Matthieu Baerts wrote:
> Hello,
>
> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
>> A previous attempt was helping, but not enough as the background
>> connections were still stopped after the timeout. That's what the MPTCP
>> CI recently reported with the "delete and re-add" subtest taking a bit
>> more than one minute in a debug environment.
>>
>> To play it safe, and because increasing the timeout for the background
>> connections doesn't change anything to the end result (the transfer is
>> not checked in this case), all subtests with a background connection not
>> waiting for it to end now have a longer timeout.
>
> I hope it is OK if I apply these patches now: they are simple, linked to
> recent patches, and we still have quite a few patches in the queue.
Done:
New patches for t/upstream-net and t/upstream:
- 16a4ac47cd40: selftests: mptcp: join: endpoints: longer timeout
- 5dd3ee3a0e67: selftests: mptcp: join: userspace: longer timeout
- Results: b6737ab5301a..7cd73169934a (export-net)
- Results: 622c76f2be66..f642d28cfc23 (export)
Tests are now in progress:
- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/660070b99dec84a338e2efd835be9a68f63316a1/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/89520dc46a1f4d65bffc7bac94b57b3ecf12cbe9/checks
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
2025-11-17 11:08 ` Matthieu Baerts
2025-11-17 11:26 ` Matthieu Baerts
@ 2025-11-18 8:43 ` Geliang Tang
2025-11-18 16:06 ` Matthieu Baerts
1 sibling, 1 reply; 8+ messages in thread
From: Geliang Tang @ 2025-11-18 8:43 UTC (permalink / raw)
To: Matthieu Baerts, MPTCP Linux
Hi Matt,
On Mon, 2025-11-17 at 12:08 +0100, Matthieu Baerts wrote:
> Hello,
>
> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
> > A previous attempt was helping, but not enough as the background
> > connections were still stopped after the timeout. That's what the
> > MPTCP
> > CI recently reported with the "delete and re-add" subtest taking a
> > bit
> > more than one minute in a debug environment.
> >
> > To play it safe, and because increasing the timeout for the
> > background
> > connections doesn't change anything to the end result (the transfer
> > is
> > not checked in this case), all subtests with a background
> > connection not
> > waiting for it to end now have a longer timeout.
>
> I hope it is OK if I apply these patches now: they are simple, linked
> to
> recent patches, and we still have quite a few patches in the queue.
>
> I'm planning to send them with other patches we have in the queue for
> net ideally today.
Sorry for the delay. I just replied my RB tags to them for -net.
Thanks,
-Geliang
>
> Cheers,
> Matt
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
2025-11-18 8:43 ` Geliang Tang
@ 2025-11-18 16:06 ` Matthieu Baerts
0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-18 16:06 UTC (permalink / raw)
To: Geliang Tang; +Cc: MPTCP Linux
Hi Geliang,
On 18/11/2025 09:43, Geliang Tang wrote:
> On Mon, 2025-11-17 at 12:08 +0100, Matthieu Baerts wrote:
>> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
>>> A previous attempt was helping, but not enough as the background
>>> connections were still stopped after the timeout. That's what the
>>> MPTCP
>>> CI recently reported with the "delete and re-add" subtest taking a
>>> bit
>>> more than one minute in a debug environment.
>>>
>>> To play it safe, and because increasing the timeout for the
>>> background
>>> connections doesn't change anything to the end result (the transfer
>>> is
>>> not checked in this case), all subtests with a background
>>> connection not
>>> waiting for it to end now have a longer timeout.
>>
>> I hope it is OK if I apply these patches now: they are simple, linked
>> to
>> recent patches, and we still have quite a few patches in the queue.
>>
>> I'm planning to send them with other patches we have in the queue for
>> net ideally today.
>
> Sorry for the delay. I just replied my RB tags to them for -net.
No problem, I'm sure that kind of simple patch in the selftests would
have been accepted without additional tags. Thank you for having sent them!
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 8+ messages in thread