1. Patchew
  2. MPTCP
  3. View series

[PATCH mptcp-net v3] mptcp: pm: kernel: c-flag: keep local_addr_used in sync

Matthieu Baerts (NGI0) posted 1 patch 6 days, 10 hours ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/multipath-tcp/mptcp_net-next tags/patchew/20261029-mptcp-pm-cflag-clear-when-used-v3-1-fa96c11f97b0@kernel.org
net/mptcp/pm_kernel.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
[PATCH mptcp-net v3] mptcp: pm: kernel: c-flag: keep local_addr_used in sync
Posted by Matthieu Baerts (NGI0) 6 days, 10 hours ago 
The ID was marked as used before incrementing local_addr_used counter
when the families were not matching.

Marking endpoints as used while they are not can have an impact on the
local_addr_used counter when endpoints not linked to the initial subflow
are removed -- CAP_NET_ADMIN is required -- and active connections have
such badly marked endpoints. In this case, the local counter will be
decremented while it shouldn't. If the counter was already at 0, this
warning will be emitted:

  WARNING: net/mptcp/pm_kernel.c:1080 at __mark_subflow_endp_available+0x46/0x50, CPU#0: a.out/149
  RIP: 0010:__mark_subflow_endp_available (net/mptcp/pm_kernel.c:1080 (discriminator 2) net/mptcp/pm_kernel.c:1076 (discriminator 2))
  Call Trace:
   mptcp_pm_nl_del_addr_doit (net/mptcp/pm_kernel.c:1112 net/mptcp/pm_kernel.c:1227)
   genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)

The fix is easy: increment local_addr_used similar to what is done in
mptcp_pm_create_subflow_or_signal_addr() for the non C-flag case.

Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Closes: https://lore.kernel.org/20261006114409.117190-1-yimingqian591@gmail.com
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Changes in v3:
- Reword commit message: the issue was only with mismatched families.
- Link to v2: https://patch.msgid.link/20261022-mptcp-pm-cflag-clear-when-used-v2-1-8c7fbe166b74@kernel.org

Changes in v2:
- Move the increment of local_addr_used before checking the family,
  similar to what is done for the non C-flag case.
- Link to v1: https://patch.msgid.link/20261022-mptcp-pm-cflag-clear-when-used-v1-1-516c09b4ee65@kernel.org
---
Note: this patch supersedes the patch mentioned above: the author
doesn't seem to be willing to send a v2. Because security@k.o was Cc'ed
on public ML, that's forcing us not to wait, even if this fix is just
about a counter that will be wrongly decremented when MPTCP endpoints
are removed (requiring CAP_NET_ADMIN). Put the original author as
"Reported-by" following the recommendations given to maintainers in such
cases.
---
 net/mptcp/pm_kernel.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index d3014bf57bf3..fb611c4b3eb8 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -584,13 +584,15 @@ fill_local_addresses_vec_c_flag(struct mptcp_sock *msk,
 
 		__clear_bit(local->addr.id, msk->pm.id_avail_bitmap);
 
-		if (!mptcp_pm_addr_families_match(sk, &local->addr, remote))
-			continue;
-
 		if (local->addr.id == msk->mpc_endpoint_id)
 			continue;
 
+		/* Increment before checking families, similar to non C-flag */
 		msk->pm.local_addr_used++;
+
+		if (!mptcp_pm_addr_families_match(sk, &local->addr, remote))
+			continue;
+
 		msk->pm.extra_subflows++;
 		i++;
 

---
base-commit: bcc5638fabf418e763621a432840cf55287e604d
change-id: 20261006-mptcp-pm-cflag-clear-when-used-ee817b26a553

Best regards,
--  
Matthieu Baerts (NGI0) <matttbe@kernel.org>
Re: [PATCH mptcp-net v3] mptcp: pm: kernel: c-flag: keep local_addr_used in sync
Posted by Geliang Tang 6 days, 4 hours ago 
Hi Matt,

On Thu, 2026-10-29 at 21:43 +0100, Matthieu Baerts (NGI0) wrote:
> The ID was marked as used before incrementing local_addr_used counter
> when the families were not matching.
> 
> Marking endpoints as used while they are not can have an impact on
> the
> local_addr_used counter when endpoints not linked to the initial
> subflow
> are removed -- CAP_NET_ADMIN is required -- and active connections
> have
> such badly marked endpoints. In this case, the local counter will be
> decremented while it shouldn't. If the counter was already at 0, this
> warning will be emitted:
> 
>   WARNING: net/mptcp/pm_kernel.c:1080 at
> __mark_subflow_endp_available+0x46/0x50, CPU#0: a.out/149
>   RIP: 0010:__mark_subflow_endp_available (net/mptcp/pm_kernel.c:1080
> (discriminator 2) net/mptcp/pm_kernel.c:1076 (discriminator 2))
>   Call Trace:
>    mptcp_pm_nl_del_addr_doit (net/mptcp/pm_kernel.c:1112
> net/mptcp/pm_kernel.c:1227)
>    genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)
> 
> The fix is easy: increment local_addr_used similar to what is done in
> mptcp_pm_create_subflow_or_signal_addr() for the non C-flag case.
> 
> Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with
> C-flag")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Closes:
> https://lore.kernel.org/20261006114409.117190-1-yimingqian591@gmail.com
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Good catch. The fix correctly restores the consistency between
id_avail_bitmap and local_addr_used, matching the non-C-flag path.

Additionally, I don't think the Perf failure (Perf: Unstable: 1 failed
test(s): error:sched-bbr) reported by the CI is related to this patch.

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

Thanks,
-Geliang

> ---
> Changes in v3:
> - Reword commit message: the issue was only with mismatched families.
> - Link to v2:
> https://patch.msgid.link/20261022-mptcp-pm-cflag-clear-when-used-v2-1-8c7fbe166b74@kernel.org
> 
> Changes in v2:
> - Move the increment of local_addr_used before checking the family,
>   similar to what is done for the non C-flag case.
> - Link to v1:
> https://patch.msgid.link/20261022-mptcp-pm-cflag-clear-when-used-v1-1-516c09b4ee65@kernel.org
> ---
> Note: this patch supersedes the patch mentioned above: the author
> doesn't seem to be willing to send a v2. Because security@k.o was
> Cc'ed
> on public ML, that's forcing us not to wait, even if this fix is just
> about a counter that will be wrongly decremented when MPTCP endpoints
> are removed (requiring CAP_NET_ADMIN). Put the original author as
> "Reported-by" following the recommendations given to maintainers in
> such
> cases.
> ---
>  net/mptcp/pm_kernel.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
> index d3014bf57bf3..fb611c4b3eb8 100644
> --- a/net/mptcp/pm_kernel.c
> +++ b/net/mptcp/pm_kernel.c
> @@ -584,13 +584,15 @@ fill_local_addresses_vec_c_flag(struct
> mptcp_sock *msk,
>  
>  		__clear_bit(local->addr.id, msk-
> >pm.id_avail_bitmap);
>  
> -		if (!mptcp_pm_addr_families_match(sk, &local->addr,
> remote))
> -			continue;
> -
>  		if (local->addr.id == msk->mpc_endpoint_id)
>  			continue;
>  
> +		/* Increment before checking families, similar to
> non C-flag */
>  		msk->pm.local_addr_used++;
> +
> +		if (!mptcp_pm_addr_families_match(sk, &local->addr,
> remote))
> +			continue;
> +
>  		msk->pm.extra_subflows++;
>  		i++;
>  
> 
> ---
> base-commit: bcc5638fabf418e763621a432840cf55287e604d
> change-id: 20261006-mptcp-pm-cflag-clear-when-used-ee817b26a553
> 
> Best regards,
> --  
> Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
Re: [PATCH mptcp-net v3] mptcp: pm: kernel: c-flag: keep local_addr_used in sync
Posted by MPTCP CI 6 days, 8 hours ago 
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! ✅
- Perf: Unstable: 1 failed test(s): error:sched-bbr ⚠️ 
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/40957519828

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


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)

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.