From nobody Fri Oct 31 16:12:51 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED0E0235341; Fri, 17 Oct 2025 07:19:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760685543; cv=none; b=Eo2yBnkepHy9L9WStm+gKJyLcG8XvDVQi/z/anuiEDLUHVpKVKeotZs40JQoeK2qRZjU2USSQ7TtvxgwhNA7zpZiSjxQsFl4yEZ3pZmEKdnX0lxHnX2jpZCMvFcRDCfXE5kFcT2rEHpLza5lq4dpBQaSvLiBaUhwhV4Z13qvJmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760685543; c=relaxed/simple; bh=neBbrk27vA6GND1zGs3pPaAxWCRrj8/pRnevn20A6EE=; h=Subject:To:Cc:From:Date:In-Reply-To:Message-ID:MIME-Version: Content-Type; b=dqB98DbbiZhy98jzXsR7nCfik9dtDYhbQPUPjSt+VnQpUz7IPULgosjmF7TfFrMjjzxln3Q+uypqZyuVL9Ib0PcLypSGbsiH7PTVyjD3Nv+rIyat4sayWvpd4fcCr/GCLah1S8anRXTTHzLebdI/1s6uvzsRhPt52Zqmbb8pA5E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=2AF8OMjZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="2AF8OMjZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 798D5C4CEF9; Fri, 17 Oct 2025 07:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1760685542; bh=neBbrk27vA6GND1zGs3pPaAxWCRrj8/pRnevn20A6EE=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=2AF8OMjZTWMvPyZnFSEAo8rnhwrC9sQJ1ZREI7qKMfcMm6X05EUeLB6zcZ5QkJjnR g6QNvYH4axTBwkbJS7QXcLE99ySOcCXs60u09Da3RV8H+s7V0I5GQ01qOX5XlwWR2j LjdNhpj8NvBXtybGFBpk1ljLFJmxRi1ON7vIUYRM= Subject: Patch "mptcp: pm: in-kernel: usable client side with C-flag" has been added to the 6.12-stable tree To: geliang@kernel.org,gregkh@linuxfoundation.org,kuba@kernel.org,matttbe@kernel.org,mptcp@lists.linux.dev Cc: From: Date: Fri, 17 Oct 2025 09:18:32 +0200 In-Reply-To: <20251016165656.940021-2-matttbe@kernel.org> Message-ID: <2025101732-devalue-jaws-06b3@gregkh> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-stable: commit X-Patchwork-Hint: ignore Content-Type: text/plain; charset="utf-8" This is a note to let you know that I've just added the patch titled mptcp: pm: in-kernel: usable client side with C-flag to the 6.12-stable tree which can be found at: http://www.kernel.org/git/?p=3Dlinux/kernel/git/stable/stable-queue.git= ;a=3Dsummary The filename of the patch is: mptcp-pm-in-kernel-usable-client-side-with-c-flag.patch and it can be found in the queue-6.12 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From stable+bounces-186178-greg=3Dkroah.com@vger.kernel.org Thu Oct 16 18:5= 7:55 2025 From: "Matthieu Baerts (NGI0)" Date: Thu, 16 Oct 2025 18:56:57 +0200 Subject: mptcp: pm: in-kernel: usable client side with C-flag To: stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: MPTCP Upstream , "Matthieu Baerts (NGI0)" , Geliang Tang , Jakub Kicinski Message-ID: <20251016165656.940021-2-matttbe@kernel.org> From: "Matthieu Baerts (NGI0)" commit 4b1ff850e0c1aacc23e923ed22989b827b9808f9 upstream. When servers set the C-flag in their MP_CAPABLE to tell clients not to create subflows to the initial address and port, clients will likely not use their other endpoints. That's because the in-kernel path-manager uses the 'subflow' endpoints to create subflows only to the initial address and port. If the limits have not been modified to accept ADD_ADDR, the client doesn't try to establish new subflows. If the limits accept ADD_ADDR, the routing routes will be used to select the source IP. The C-flag is typically set when the server is operating behind a legacy Layer 4 load balancer, or using anycast IP address. Clients having their different 'subflow' endpoints setup, don't end up creating multiple subflows as expected, and causing some deployment issues. A special case is then added here: when servers set the C-flag in the MPC and directly sends an ADD_ADDR, this single ADD_ADDR is accepted. The 'subflows' endpoints will then be used with this new remote IP and port. This exception is only allowed when the ADD_ADDR is sent immediately after the 3WHS, and makes the client switching to the 'fully established' mode. After that, 'select_local_address()' will not be able to find any subflows, because 'id_avail_bitmap' will be filled in mptcp_pm_create_subflow_or_signal_addr(), when switching to 'fully established' mode. Fixes: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/536 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250925-net-next-mptcp-c-flag-laminar-v1-1-= ad126cc47c6b@kernel.org Signed-off-by: Jakub Kicinski [ Conflict in pm.c, because commit 498d7d8b75f1 ("mptcp: pm: remove '_nl' from mptcp_pm_nl_is_init_remote_addr") renamed an helper in the context, and it is not in this version. The same new code can be applied at the same place. Conflict in pm_kernel.c, because the modified code has been moved from pm_netlink.c to pm_kernel.c in commit 8617e85e04bd ("mptcp: pm: split in-kernel PM specific code"), which is not in this version. The resolution is easy: simply by applying the patch where 'pm_kernel.c' has been replaced 'pm_netlink.c'. 'patch --merge' managed to apply this modified patch without creating any conflicts. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman --- net/mptcp/pm.c | 7 ++++-- net/mptcp/pm_netlink.c | 50 ++++++++++++++++++++++++++++++++++++++++++++= ++++- net/mptcp/protocol.h | 8 +++++++ 3 files changed, 62 insertions(+), 3 deletions(-) --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -226,9 +226,12 @@ void mptcp_pm_add_addr_received(const st } else { __MPTCP_INC_STATS(sock_net((struct sock *)msk), MPTCP_MIB_ADDADDRDROP); } - /* id0 should not have a different address */ + /* - id0 should not have a different address + * - special case for C-flag: linked to fill_local_addresses_vec() + */ } else if ((addr->id =3D=3D 0 && !mptcp_pm_nl_is_init_remote_addr(msk, ad= dr)) || - (addr->id > 0 && !READ_ONCE(pm->accept_addr))) { + (addr->id > 0 && !READ_ONCE(pm->accept_addr) && + !mptcp_pm_add_addr_c_flag_case(msk))) { mptcp_pm_announce_addr(msk, addr, true); mptcp_pm_add_addr_send_ack(msk); } else if (mptcp_pm_schedule_work(msk, MPTCP_PM_ADD_ADDR_RECEIVED)) { --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -674,10 +674,12 @@ static unsigned int fill_local_addresses struct mptcp_addr_info mpc_addr; struct pm_nl_pernet *pernet; unsigned int subflows_max; + bool c_flag_case; int i =3D 0; =20 pernet =3D pm_nl_get_pernet_from_msk(msk); subflows_max =3D mptcp_pm_get_subflows_max(msk); + c_flag_case =3D remote->id && mptcp_pm_add_addr_c_flag_case(msk); =20 mptcp_local_address((struct sock_common *)msk, &mpc_addr); =20 @@ -690,12 +692,27 @@ static unsigned int fill_local_addresses continue; =20 if (msk->pm.subflows < subflows_max) { + bool is_id0; + locals[i].addr =3D entry->addr; locals[i].flags =3D entry->flags; locals[i].ifindex =3D entry->ifindex; =20 + is_id0 =3D mptcp_addresses_equal(&locals[i].addr, + &mpc_addr, + locals[i].addr.port); + + if (c_flag_case && + (entry->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW)) { + __clear_bit(locals[i].addr.id, + msk->pm.id_avail_bitmap); + + if (!is_id0) + msk->pm.local_addr_used++; + } + /* Special case for ID0: set the correct ID */ - if (mptcp_addresses_equal(&locals[i].addr, &mpc_addr, locals[i].addr.po= rt)) + if (is_id0) locals[i].addr.id =3D 0; =20 msk->pm.subflows++; @@ -704,6 +721,37 @@ static unsigned int fill_local_addresses } rcu_read_unlock(); =20 + /* Special case: peer sets the C flag, accept one ADD_ADDR if default + * limits are used -- accepting no ADD_ADDR -- and use subflow endpoints + */ + if (!i && c_flag_case) { + unsigned int local_addr_max =3D mptcp_pm_get_local_addr_max(msk); + + while (msk->pm.local_addr_used < local_addr_max && + msk->pm.subflows < subflows_max) { + struct mptcp_pm_local *local =3D &locals[i]; + + if (!select_local_address(pernet, msk, local)) + break; + + __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); + + if (!mptcp_pm_addr_families_match(sk, &local->addr, + remote)) + continue; + + if (mptcp_addresses_equal(&local->addr, &mpc_addr, + local->addr.port)) + continue; + + msk->pm.local_addr_used++; + msk->pm.subflows++; + i++; + } + + return i; + } + /* If the array is empty, fill in the single * 'IPADDRANY' local address */ --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -1172,6 +1172,14 @@ static inline void mptcp_pm_close_subflo spin_unlock_bh(&msk->pm.lock); } =20 +static inline bool mptcp_pm_add_addr_c_flag_case(struct mptcp_sock *msk) +{ + return READ_ONCE(msk->pm.remote_deny_join_id0) && + msk->pm.local_addr_used =3D=3D 0 && + mptcp_pm_get_add_addr_accept_max(msk) =3D=3D 0 && + msk->pm.subflows < mptcp_pm_get_subflows_max(msk); +} + void mptcp_sockopt_sync_locked(struct mptcp_sock *msk, struct sock *ssk); =20 static inline struct mptcp_ext *mptcp_get_ext(const struct sk_buff *skb) Patches currently in stable-queue which might be from matttbe@kernel.org are queue-6.12/mptcp-pm-in-kernel-usable-client-side-with-c-flag.patch queue-6.12/selftests-mptcp-join-validate-c-flag-def-limit.patch