In this "delete re-add signal" MPTCP Join subtest, the endpoint linked
to the initial subflow is removed, but readded once with different ID.

It appears that there was an issue when reusing the same ID, recently
fixed by commit d191101dee25 ("mptcp: pm: in-kernel: always set ID as
avail when rm endp"). The test then now reuses the same ID the first
time, but continue to use another one (88) the second time.

This should then cover more cases.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/615
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index dc1f200aaa81..e22ed8cab27e 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -4294,13 +4294,13 @@ endpoint_tests()
 		chk_mptcp_info subflows 2 subflows 2
 		chk_mptcp_info add_addr_signal 2 add_addr_accepted 2
 
-		pm_nl_add_endpoint $ns1 10.0.1.1 id 99 flags signal
+		pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal
 		wait_mpj 4
 		chk_subflow_nr "after re-add ID 0" 3
 		chk_mptcp_info subflows 3 subflows 3
 		chk_mptcp_info add_addr_signal 3 add_addr_accepted 2
 
-		pm_nl_del_endpoint $ns1 99 10.0.1.1
+		pm_nl_del_endpoint $ns1 42 10.0.1.1
 		sleep 0.5
 		chk_subflow_nr "after re-delete ID 0" 2
 		chk_mptcp_info subflows 2 subflows 2

---
base-commit: db54d4a79a413b2702191c0dc1d855bc3c9e1a98
change-id: 20260223-mptcp-sft-re-use-id-c06c69316205

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

Hi Matt,

Thanks for this patch.

On Mon, 2026-02-23 at 19:46 +0100, Matthieu Baerts (NGI0) wrote:
> In this "delete re-add signal" MPTCP Join subtest, the endpoint
> linked
> to the initial subflow is removed, but readded once with different
> ID.
> 
> It appears that there was an issue when reusing the same ID, recently
> fixed by commit d191101dee25 ("mptcp: pm: in-kernel: always set ID as
> avail when rm endp"). The test then now reuses the same ID the first
> time, but continue to use another one (88) the second time.
> 
> This should then cover more cases.
> 
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/615
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Looks good to me.

    Reviewed-by: Geliang Tang <geliang@kernel.org>

-Geliang

> ---
>  tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> index dc1f200aaa81..e22ed8cab27e 100755
> --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> @@ -4294,13 +4294,13 @@ endpoint_tests()
>  		chk_mptcp_info subflows 2 subflows 2
>  		chk_mptcp_info add_addr_signal 2 add_addr_accepted 2
>  
> -		pm_nl_add_endpoint $ns1 10.0.1.1 id 99 flags signal
> +		pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal
>  		wait_mpj 4
>  		chk_subflow_nr "after re-add ID 0" 3
>  		chk_mptcp_info subflows 3 subflows 3
>  		chk_mptcp_info add_addr_signal 3 add_addr_accepted 2
>  
> -		pm_nl_del_endpoint $ns1 99 10.0.1.1
> +		pm_nl_del_endpoint $ns1 42 10.0.1.1
>  		sleep 0.5
>  		chk_subflow_nr "after re-delete ID 0" 2
>  		chk_mptcp_info subflows 2 subflows 2
> 
> ---
> base-commit: db54d4a79a413b2702191c0dc1d855bc3c9e1a98
> change-id: 20260223-mptcp-sft-re-use-id-c06c69316205
> 
> Best regards,

Hi Geliang,

On 26/02/2026 02:58, Geliang Tang wrote:
> Hi Matt,
> 
> Thanks for this patch.
> 
> On Mon, 2026-02-23 at 19:46 +0100, Matthieu Baerts (NGI0) wrote:
>> In this "delete re-add signal" MPTCP Join subtest, the endpoint
>> linked
>> to the initial subflow is removed, but readded once with different
>> ID.
>>
>> It appears that there was an issue when reusing the same ID, recently
>> fixed by commit d191101dee25 ("mptcp: pm: in-kernel: always set ID as
>> avail when rm endp"). The test then now reuses the same ID the first
>> time, but continue to use another one (88) the second time.
>>
>> This should then cover more cases.
>>
>> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/615
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> 
> Looks good to me.
> 
>     Reviewed-by: Geliang Tang <geliang@kernel.org>

Thank you for the review!

New patches for t/upstream:
- aa395cce7724: selftests: mptcp: join: recreate signal endp with same ID
- Results: cc839747fb54..8e5eefda4630 (export)

Tests are now in progress:

- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/8c746bc846a4148976c11a69c1175a049fff5da7/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

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): Success! ✅
- 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/22320793380

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/334f2997e09c
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1056723


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)