This validates the previous commit: endpoints with both the signal and
subflow flags should always be marked as used even if it was not
possible to create new subflows due to the MPTCP PM limits.

For this test, an extra endpoint is created with both the signal and the
subflow flags, and limits are set not to create extra subflows. In this
case, an ADD_ADDR is sent, but no subflows are created. Still, the local
endpoint is marked as used, and no warning is fired when removing the
endpoint, after having sent a RM_ADDR.

The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.

Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Linked to "mptcp: pm: in-kernel: always mark signal+subflow endp as
used" sent earlier.

Based-on: <20260218-mptcp-issue-613-v1-1-f8e9adb12010@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index dc1f200aaa81..afb6fd3daced 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -2608,6 +2608,19 @@ remove_tests()
 		chk_rst_nr 0 0
 	fi
 
+	# signal+subflow with limits, remove
+	if reset "remove signal+subflow with limits"; then
+		pm_nl_set_limits $ns1 0 0
+		pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,subflow
+		pm_nl_set_limits $ns2 0 0
+		addr_nr_ns1=-1 speed=slow \
+			run_tests $ns1 $ns2 10.0.1.1
+		chk_join_nr 0 0 0
+		chk_add_nr 1 1
+		chk_rm_nr 1 0 invert
+		chk_rst_nr 0 0
+	fi
+
 	# addresses remove
 	if reset "remove addresses"; then
 		pm_nl_set_limits $ns1 3 3
-- 
2.51.0

On Thu, 19 Feb 2026, Matthieu Baerts (NGI0) wrote:

> This validates the previous commit: endpoints with both the signal and
> subflow flags should always be marked as used even if it was not
> possible to create new subflows due to the MPTCP PM limits.
>
> For this test, an extra endpoint is created with both the signal and the
> subflow flags, and limits are set not to create extra subflows. In this
> case, an ADD_ADDR is sent, but no subflows are created. Still, the local
> endpoint is marked as used, and no warning is fired when removing the
> endpoint, after having sent a RM_ADDR.
>
> The 'Fixes' tag here below is the same as the one from the previous
> commit: this patch here is not fixing anything wrong in the selftests,
> but it validates the previous fix for an issue introduced by this commit
> ID.
>
> Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set")
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> Linked to "mptcp: pm: in-kernel: always mark signal+subflow endp as
> used" sent earlier.
>
> Based-on: <20260218-mptcp-issue-613-v1-1-f8e9adb12010@kernel.org>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Reviewed-by: Mat Martineau <martineau@kernel.org>

> ---
> tools/testing/selftests/net/mptcp/mptcp_join.sh | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> index dc1f200aaa81..afb6fd3daced 100755
> --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> @@ -2608,6 +2608,19 @@ remove_tests()
> 		chk_rst_nr 0 0
> 	fi
>
> +	# signal+subflow with limits, remove
> +	if reset "remove signal+subflow with limits"; then
> +		pm_nl_set_limits $ns1 0 0
> +		pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,subflow
> +		pm_nl_set_limits $ns2 0 0
> +		addr_nr_ns1=-1 speed=slow \
> +			run_tests $ns1 $ns2 10.0.1.1
> +		chk_join_nr 0 0 0
> +		chk_add_nr 1 1
> +		chk_rm_nr 1 0 invert
> +		chk_rst_nr 0 0
> +	fi
> +
> 	# addresses remove
> 	if reset "remove addresses"; then
> 		pm_nl_set_limits $ns1 3 3
> -- 
> 2.51.0
>
>
>

Hi Mat,

On 25/02/2026 18:51, Mat Martineau wrote:
> On Thu, 19 Feb 2026, Matthieu Baerts (NGI0) wrote:
> 
>> This validates the previous commit: endpoints with both the signal and
>> subflow flags should always be marked as used even if it was not
>> possible to create new subflows due to the MPTCP PM limits.
>>
>> For this test, an extra endpoint is created with both the signal and the
>> subflow flags, and limits are set not to create extra subflows. In this
>> case, an ADD_ADDR is sent, but no subflows are created. Still, the local
>> endpoint is marked as used, and no warning is fired when removing the
>> endpoint, after having sent a RM_ADDR.
>>
>> The 'Fixes' tag here below is the same as the one from the previous
>> commit: this patch here is not fixing anything wrong in the selftests,
>> but it validates the previous fix for an issue introduced by this commit
>> ID.
>>
>> Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal'
>> flag is also set")
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>> Linked to "mptcp: pm: in-kernel: always mark signal+subflow endp as
>> used" sent earlier.
>>
>> Based-on: <20260218-mptcp-issue-613-v1-1-f8e9adb12010@kernel.org>
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> 
> Reviewed-by: Mat Martineau <martineau@kernel.org>

Thank you for the review!

Now in our tree:

New patches for t/upstream-net and t/upstream:
- 402de2bca118: mptcp: pm: in-kernel: always mark signal+subflow endp as
used
- e8f38bbd8b67: selftests: mptcp: join: check removing signal+subflow endp
- Results: 652750a9d6a6..eefe19f1a175 (export-net)
- Results: d3854ef490c9..c0858783271a (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/ca3a60dc7df9f019289be14d7ca6898f8431381e/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/866d58409123388cf9032de57af875fbe418a642/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): Unstable: 1 failed test(s): selftest_mptcp_connect - Notice: Call Traces at boot time, rebooted and continued 🔴
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): packetdrill_dss 🔴
- 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/22177895301

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


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)