From nobody Mon May 25 03:35:40 2026 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 AB0D3413233; Fri, 8 May 2026 17:40:27 +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=1778262027; cv=none; b=YGB8KaMfWxDwKjC0aHomYjBktgO15Zg2a9YLr4Sohdt5Fq9gpge609m7OnBxtHuY9+1qDg9ILMsiMonBP3O3gSlUg/TZu0YZrzoF3uUOH0PlJopbXqy9ZUNoj+Gjri6F8iDhDZxzxZoUBy9WWsFNGgb0m0AM1JsmKYMOTtGWiKQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262027; c=relaxed/simple; bh=CqDKsEm1PYL9sdOBUwHtAe1dz4oOGbRt8O/PkmSdQA8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=fLGMFGOlgH10mIZa2c4tRoJRK6UVfcCW4LcyTy0CrPTBRFFMFgKASqCB7OKIbSSnltRhw6OXiQq4wgrv2ecpZs1CHQBqIobJYZjKnBF0WQq5U5tJgniCqVfHQ08w9E1xdvq2+eARJQAbKLhu+KWH8U53qMu9dD+lkg4lxDNzjLQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K894pWl6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K894pWl6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98C9EC2BCC7; Fri, 8 May 2026 17:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262027; bh=CqDKsEm1PYL9sdOBUwHtAe1dz4oOGbRt8O/PkmSdQA8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=K894pWl6SClYHopfFquNvY/KS3SA7J3d879taWfkA8OWPRknDZRBdEm/RV69TLaLy llp6Vhe9XQqQ8hd7JnpgIjGyve0+zn5y/aNeShppvBU2M2Z2+r+foTxuqK4gYqIKt6 1AaW/WP3gBixFx8qvhLMMfVP/rTa45mAmW/l8ioIssKHilCJG6ivWwo3gG42HBSRtH Sosq4Us2rsigACTinuy6VlEPPLIVKtkm/QPwb3UK0Yk6Cc7AhrS0mG1hYnxFfm/4jC uStC4Wc9jSMdS+90TCOXEC5XHMfIS2ib45p791Nflu3H3cA7qEenXLGWZghycWBSoJ zBmUEokKHjAhw== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:46 +0200 Subject: [PATCH net-next 1/8] mptcp: pm: in-kernel: explicitly limit batches to array size Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-1-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=5750; i=matttbe@kernel.org; h=from:subject:message-id; bh=CqDKsEm1PYL9sdOBUwHtAe1dz4oOGbRt8O/PkmSdQA8=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KTAqLF2rF/757JMvR1b8Y7rXLvU2W/O4dpcr98uby 18nRfMod5SyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAEwk9BLDX6Et2Usczu+dOPPs pq83fATLnu6rXrY0UFWNcY2y9i+xWacZGbrbH29WbZGZu6hG+83vbNPLSwKCpEydFDxPcirW/dA zYAQA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The in-kernel PM can create subflows in reply to ADD_ADDR by batch of maximum 8 subflows for the moment. Same when adding new "subflow" endpoints with the fullmesh flag. This limit is linked to the arrays used during these steps. There was no explicit limit to the arrays size (8), because the limit of extra subflows is the same (8). It seems safer to use an explicit limit, but also these two sizes are going to be different in the next commit. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_kernel.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index fc818b63752e..f8987a33bed4 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -201,7 +201,8 @@ fill_remote_addr(struct mptcp_sock *msk, struct mptcp_a= ddr_info *local, static unsigned int fill_remote_addresses_fullmesh(struct mptcp_sock *msk, struct mptcp_addr_info *local, - struct mptcp_addr_info *addrs) + struct mptcp_addr_info *addrs, + int addrs_size) { u8 limit_extra_subflows =3D mptcp_pm_get_limit_extra_subflows(msk); bool deny_id0 =3D READ_ONCE(msk->pm.remote_deny_join_id0); @@ -236,7 +237,8 @@ fill_remote_addresses_fullmesh(struct mptcp_sock *msk, msk->pm.extra_subflows++; i++; =20 - if (msk->pm.extra_subflows >=3D limit_extra_subflows) + if (msk->pm.extra_subflows >=3D limit_extra_subflows || + i =3D=3D addrs_size) break; } =20 @@ -248,7 +250,8 @@ fill_remote_addresses_fullmesh(struct mptcp_sock *msk, */ static unsigned int fill_remote_addresses_vec(struct mptcp_sock *msk, struct mptcp_addr_info *= local, - bool fullmesh, struct mptcp_addr_info *addrs) + bool fullmesh, struct mptcp_addr_info *addrs, + int addrs_size) { /* Non-fullmesh: fill in the single entry corresponding to the primary * MPC subflow remote address, and return 1, corresponding to 1 entry. @@ -257,7 +260,7 @@ fill_remote_addresses_vec(struct mptcp_sock *msk, struc= t mptcp_addr_info *local, return fill_remote_addr(msk, local, addrs); =20 /* Fullmesh endpoint: fill all possible remote addresses */ - return fill_remote_addresses_fullmesh(msk, local, addrs); + return fill_remote_addresses_fullmesh(msk, local, addrs, addrs_size); } =20 static struct mptcp_pm_addr_entry * @@ -410,7 +413,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) else /* local_addr_used is not decr for ID 0 */ msk->pm.local_addr_used++; =20 - nr =3D fill_remote_addresses_vec(msk, &local.addr, fullmesh, addrs); + nr =3D fill_remote_addresses_vec(msk, &local.addr, fullmesh, + addrs, ARRAY_SIZE(addrs)); if (nr =3D=3D 0) continue; =20 @@ -447,6 +451,7 @@ static unsigned int fill_local_addresses_vec_fullmesh(struct mptcp_sock *msk, struct mptcp_addr_info *remote, struct mptcp_pm_local *locals, + int locals_size, bool c_flag_case) { u8 limit_extra_subflows =3D mptcp_pm_get_limit_extra_subflows(msk); @@ -488,7 +493,8 @@ fill_local_addresses_vec_fullmesh(struct mptcp_sock *ms= k, msk->pm.extra_subflows++; i++; =20 - if (msk->pm.extra_subflows >=3D limit_extra_subflows) + if (msk->pm.extra_subflows >=3D limit_extra_subflows || + i =3D=3D locals_size) break; } rcu_read_unlock(); @@ -559,7 +565,8 @@ fill_local_laminar_endp(struct mptcp_sock *msk, struct = mptcp_addr_info *remote, static unsigned int fill_local_addresses_vec_c_flag(struct mptcp_sock *msk, struct mptcp_addr_info *remote, - struct mptcp_pm_local *locals) + struct mptcp_pm_local *locals, + int locals_size) { u8 limit_extra_subflows =3D mptcp_pm_get_limit_extra_subflows(msk); struct pm_nl_pernet *pernet =3D pm_nl_get_pernet_from_msk(msk); @@ -586,7 +593,8 @@ fill_local_addresses_vec_c_flag(struct mptcp_sock *msk, msk->pm.extra_subflows++; i++; =20 - if (msk->pm.extra_subflows >=3D limit_extra_subflows) + if (msk->pm.extra_subflows >=3D limit_extra_subflows || + i =3D=3D locals_size) break; } =20 @@ -620,13 +628,14 @@ fill_local_address_any(struct mptcp_sock *msk, struct= mptcp_addr_info *remote, */ static unsigned int fill_local_addresses_vec(struct mptcp_sock *msk, struct mptcp_addr_info *r= emote, - struct mptcp_pm_local *locals) + struct mptcp_pm_local *locals, int locals_size) { bool c_flag_case =3D remote->id && mptcp_pm_add_addr_c_flag_case(msk); =20 /* If there is at least one MPTCP endpoint with a fullmesh flag */ if (mptcp_pm_get_endp_fullmesh_max(msk)) return fill_local_addresses_vec_fullmesh(msk, remote, locals, + locals_size, c_flag_case); =20 /* If there is at least one MPTCP endpoint with a laminar flag */ @@ -637,7 +646,8 @@ fill_local_addresses_vec(struct mptcp_sock *msk, struct= mptcp_addr_info *remote, * limits are used -- accepting no ADD_ADDR -- and use subflow endpoints */ if (c_flag_case) - return fill_local_addresses_vec_c_flag(msk, remote, locals); + return fill_local_addresses_vec_c_flag(msk, remote, locals, + locals_size); =20 /* No special case: fill in the single 'IPADDRANY' local address */ return fill_local_address_any(msk, remote, &locals[0]); @@ -672,7 +682,7 @@ static void mptcp_pm_nl_add_addr_received(struct mptcp_= sock *msk) /* connect to the specified remote address, using whatever * local address the routing configuration will pick. */ - nr =3D fill_local_addresses_vec(msk, &remote, locals); + nr =3D fill_local_addresses_vec(msk, &remote, locals, ARRAY_SIZE(locals)); if (nr =3D=3D 0) return; =20 --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 BFF32413223; Fri, 8 May 2026 17:40:29 +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=1778262029; cv=none; b=dFvnrpaGlHWH2Itefm+0BN0/XhFO7wduwKlnIw/64u0dXcpgVSZiAg6AkcgJs0jbbVCFoP53qt+YmITQRzFFzeMGcv+wzoiKDzetgt9ggDdpSA9kz9MqXBBsGbKy0C1sVteabTilO4IaL0K9IcUzSsRaoLm4H8KPnfDlKHKlW3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262029; c=relaxed/simple; bh=ChYyR8m0KntemIUgUhus0V3d5Xjk7lIn7Zs3/5xUEXs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=YAugyoGBJPdGDVkjzTyvONqUsaKW8ErT0prUj5Wj2DbQn98Rtcy8wp0ebkeISi3OSza5Jo626bhVitFHNf3vIojUoYBZH4+8TxNkNY/sLpRgUPwfFGMT5ik6+//RZ6NPmf4P5M2fBeMyXTOv3lEcC/tAF8vo34rbs+qmJh3WTVE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GCCOukoX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GCCOukoX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC576C2BCC9; Fri, 8 May 2026 17:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262029; bh=ChYyR8m0KntemIUgUhus0V3d5Xjk7lIn7Zs3/5xUEXs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=GCCOukoX46awkCDnJceAsD6tmYWCAhD3lsQoJotQM6dntW5EC47mJn6+locodz8Wb byOA3qVrdcmykLNtLDXv3v2g056BZs/iybtFBxGWheIdSeKjt+NWRJEOGfH8CVE1hN dORvQrEkR8g8vQiKBk/lA/mGk7rV3ItCewrEwu+3xVYotsxVGjdF+JLxRj0ZCfGxqS p2/zlSJTnHnHQwnm4jLD2e6w1qhD46nTsz0g6ny1egd3LF2ZHOiHjV+5LNq9U2HU2A tmbEwwCQ3shJS5Otl492AXob+O9wvrOYWWqki+/RmZvT9ayQZLFJyinH+tIUNkm0B3 8YmesyeUiPfUQ== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:47 +0200 Subject: [PATCH net-next 2/8] mptcp: pm: in-kernel: increase all limits to 64 Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-2-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2263; i=matttbe@kernel.org; h=from:subject:message-id; bh=ChYyR8m0KntemIUgUhus0V3d5Xjk7lIn7Zs3/5xUEXs=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KTBeav7rX1H2I95lepyMbJVW/c61yiJde3t3nOIIW V630V6yo5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCJbDjP8lRZrD5cWly8K2fPr 4tO3btpTOvbPcn507Pq73Quv1M2VdGX4xfzv4G3bws4XJzfsF5tQukT88p/dFdNrmHaXXpleM+/ XAS4A X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 This means switching the maximum from 8 to 64 for the number of subflows and accepted ADD_ADDR. The previous limit of 8 subflows makes sense in most cases. Using more subflows will very likely *not* improve the situation, and could even decrease the performances. But there are no technical limitations nor performance impact to raise this limit, so let's do it: this will allow people with very specific use-cases, and researchers to easily create more subflows, and measure the performance impact by themselves. The theoretical limit is 255 -- the ID is written in a u8 on the wire -- but 64 is more than enough. With so many subflows, it will be costly to iterate over all of them when operations are done in bottom half. Note that the in-kernel PM will continue to create subflows in reply to ADD_ADDR with a single batch of maximum 8 subflows. Same when adding new "subflow" endpoints with the fullmesh flag. Increasing those batch limits would have a memory impact, and it looks fine not to cover these cases with larger batches for the moment. If more is needed later, the position of the last subflow from the list could be remembered, and the list iteration could continue later. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/434 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_kernel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index f8987a33bed4..aabd73d15c15 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -30,6 +30,7 @@ struct pm_nl_pernet { }; =20 #define MPTCP_PM_ADDR_MAX 8 +#define MPTCP_PM_SUBFLOWS_MAX 64 =20 static struct pm_nl_pernet *pm_nl_get_pernet(const struct net *net) { @@ -1381,10 +1382,10 @@ static int parse_limit(struct genl_info *info, int = id, unsigned int *limit) return 0; =20 *limit =3D nla_get_u32(attr); - if (*limit > MPTCP_PM_ADDR_MAX) { + if (*limit > MPTCP_PM_SUBFLOWS_MAX) { NL_SET_ERR_MSG_ATTR_FMT(info->extack, attr, "limit greater than maximum (%u)", - MPTCP_PM_ADDR_MAX); + MPTCP_PM_SUBFLOWS_MAX); return -EINVAL; } return 0; --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 D0C5B41324B; Fri, 8 May 2026 17:40:31 +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=1778262033; cv=none; b=BnDRLO6A4czDn7DaK46vqvOF+dyW0k0NhtF3JFuebLNhFO6e3yrFRIKMYi6aIxBMb+cODQ3hvfq/U8UxqBxRgVLfBEvpjdZgtIwDRUneB4svb7hri3tVoEnWxa2kgp9jXjFZ9nQB9Xs6tYL7xE+BW7rAyP7LmyzY9qqQiWbENlk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262033; c=relaxed/simple; bh=TypKKwe40llOLQhS8qZvR7uyooyh9jj+EVlTImjcMfA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bDtcLdFiqeOjd5UVmS+waI14jCYk8tnt9gFcN6jPMIj5q19ADTd0xypxG6f/aljSoKuDYeNwFXJXRhEZ+xsw33W/dOW60wBhZBQG0eGZUjH4wfiVX2SH6dlr0RqN1mk+UPVtE4y20WcqEe0mX0F0bilLCnqvCpCIHYtMDkvD2Dk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mxeyra2q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mxeyra2q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEB03C2BCC7; Fri, 8 May 2026 17:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262031; bh=TypKKwe40llOLQhS8qZvR7uyooyh9jj+EVlTImjcMfA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Mxeyra2qDyv+fBJx9YAgTnq6n2YhJy87pUXNbYTqyO23ZxyL8CUkkzYozCVV+eYTv zRIUxpEgxkOpSh4D3aG1Hj23nIew1gnsFIF3dIRAU0nUeMMUEDxUjk1iF01m9MVzL1 W2MND7IGgeT47Xb7gQQ2sf+VUhQSIP9qQ26b7BJwoq6Ceh5ki1FpUFRkLyzfZWM44g WbUHFYV8zCWR7loLp2bO0cDVtfqvqYT1j2Qv9c9sM4pzDmWW3YHHro0aF6l/UrAjBJ WxYTfkobeLCcqNw5PKqgMbAA/dazjn+oZJUMFzJQQY+1GLAy9CPGHSWR8vTogezT+4 IfmEmTPZK9Kwg== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:48 +0200 Subject: [PATCH net-next 3/8] mptcp: pm: kernel: allow flushing more than 8 endpoints Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-3-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3253; i=matttbe@kernel.org; h=from:subject:message-id; bh=TypKKwe40llOLQhS8qZvR7uyooyh9jj+EVlTImjcMfA=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KTBdebagRHzfWSO2d5Ov8q/uS5g/9ZyVN8OzQwx7/ nY/enFQv6OUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAi+vIMf7gaC/9Kbvris2T+ iaCLd06detf8qLZMLufy69KonI6Flz8x/LMLvR+71v/GUa1Wnzv+OvNWaj57c8c3eeKrfSfWxtx am8gNAA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The mptcp_rm_list structure contains an array of IDs of 8 entries: to be able to send a RM_ADDR with 8 IDs. This limitation was OK so far because there could maximum 8 endpoints. But this is going to change in the next commit. To cope with that, if one of the arrays is full, the iteration stops, the lists are processed, then the iteration continues where it previously stopped. Note that if there are many endpoints to remove, and multiple RM_ADDR to send, it might be more likely that some of these RM_ADDRs are dropped or lost. This is a known limitation: RM_ADDR are not retransmitted in MPTCPv1. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_kernel.c | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index aabd73d15c15..ea3a7ea82013 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -1223,19 +1223,30 @@ int mptcp_pm_nl_del_addr_doit(struct sk_buff *skb, = struct genl_info *info) } =20 static void mptcp_pm_flush_addrs_and_subflows(struct mptcp_sock *msk, - struct list_head *rm_list) + struct list_head *rm_list, + struct mptcp_pm_addr_entry *entry) { - struct mptcp_rm_list alist =3D { .nr =3D 0 }, slist =3D { .nr =3D 0 }; - struct mptcp_pm_addr_entry *entry; + struct mptcp_rm_list alist, slist; + bool more; =20 - list_for_each_entry(entry, rm_list, list) { - if (slist.nr < MPTCP_RM_IDS_MAX && - mptcp_lookup_subflow_by_saddr(&msk->conn_list, &entry->addr)) +again: + alist.nr =3D 0; + slist.nr =3D 0; + more =3D false; + + entry =3D list_prepare_entry(entry, rm_list, list); + list_for_each_entry_continue(entry, rm_list, list) { + if (mptcp_lookup_subflow_by_saddr(&msk->conn_list, &entry->addr)) slist.ids[slist.nr++] =3D mptcp_endp_get_local_id(msk, &entry->addr); =20 - if (alist.nr < MPTCP_RM_IDS_MAX && - mptcp_remove_anno_list_by_saddr(msk, &entry->addr)) + if (mptcp_remove_anno_list_by_saddr(msk, &entry->addr)) alist.ids[alist.nr++] =3D mptcp_endp_get_local_id(msk, &entry->addr); + + if (slist.nr =3D=3D MPTCP_RM_IDS_MAX || + alist.nr =3D=3D MPTCP_RM_IDS_MAX) { + more =3D !list_is_last(&entry->list, rm_list); + break; + } } =20 spin_lock_bh(&msk->pm.lock); @@ -1246,9 +1257,14 @@ static void mptcp_pm_flush_addrs_and_subflows(struct= mptcp_sock *msk, if (slist.nr) mptcp_pm_rm_subflow(msk, &slist); /* Reset counters: maybe some subflows have been removed before */ - bitmap_fill(msk->pm.id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); - msk->pm.local_addr_used =3D 0; + if (!more) { + bitmap_fill(msk->pm.id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1); + msk->pm.local_addr_used =3D 0; + } spin_unlock_bh(&msk->pm.lock); + + if (more) + goto again; } =20 static void mptcp_nl_flush_addrs_list(struct net *net, @@ -1265,7 +1281,7 @@ static void mptcp_nl_flush_addrs_list(struct net *net, =20 if (!mptcp_pm_is_userspace(msk)) { lock_sock(sk); - mptcp_pm_flush_addrs_and_subflows(msk, rm_list); + mptcp_pm_flush_addrs_and_subflows(msk, rm_list, NULL); release_sock(sk); } =20 --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 A541E2566F7; Fri, 8 May 2026 17:40:33 +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=1778262033; cv=none; b=WHsLt+bNmxlQZzRK3mYYrNcoSN8BllqLVmkT9VpW5MsqgVQ3ia5VJe+qdiLiPsEwvQxqqhyf6GkSd1rCIb+X2EbZUcG/6NOUqLyoSFYNHiaOP+mT0n+nbX6jC7NRGw99xzTPPciRCeFYO2vnfd/otgt8BY8nWYzFoVwGy/I45D8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262033; c=relaxed/simple; bh=GXQ5B1E4M/10/Qhs297jUYWm95hJVGjkrfRK8xxzgRg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=LB52s5EsJU10t9koJNuqc7qVfZ7qzSdn+Vc7PnrpBqMBGuINtcyg8/yZssSHLyYbzXWlO3UbR8EuM5XEBnmJbcKDtcRqcxIRtJcu1gP5IRvlsyf/bDx0tw4QSNDVHsNdTi16bDZPuYq9YVOiZTvaYFuF6be5v4sbnEzdPAPdKNU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qgb/oTAG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qgb/oTAG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D15D1C2BCB0; Fri, 8 May 2026 17:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262033; bh=GXQ5B1E4M/10/Qhs297jUYWm95hJVGjkrfRK8xxzgRg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=qgb/oTAGNVPb0Nva+oNEMhOZBH9r4l/H+XsomVNaoOkPhk8wDd4D1W3sAp9J43U10 LDuRhayRSEZ4ZbL/k+zaRCudW2U62HWLc8Hz/SCzPmuiej73Am7kaxXK+tWe5BNNAK FFtJohz0eui1M4bXsBnUuB4nJwaOsTCAo64w1fR577QuVbsBhnQb5KARhQBOOQie61 IQf6d8pylYO9k37YixpveFLWKyXpSpRq2BrjxD7XJXG3azj3+ur90G5z/rTrFtALnr JJfgBuAQonzCR4qPqP7UIUGbytceo7yb87F/8Vki+ollVKuC7JjYMVBK6OQYFrCs3C eLi+ThUMNoMOw== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:49 +0200 Subject: [PATCH net-next 4/8] mptcp: pm: in-kernel: increase endpoints limit Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-4-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1233; i=matttbe@kernel.org; h=from:subject:message-id; bh=GXQ5B1E4M/10/Qhs297jUYWm95hJVGjkrfRK8xxzgRg=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KTAr7POvLTcsSt9VLjbt9fOtTU/5ebQXid50vz7Vc 9vD1jarjlIWBjEuBlkxRRbptsj8mc+reEu8/Cxg5rAygQxh4OIUgIncFWJk+GQccSHeqFrW7RWr veDqhgNPpzVYXS748bDqmLmhiojPNEaG/bUMnO/eKdkePTiB40rjw6BbrXNm1ISI3pdz9K636Lv ECgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The endpoints are managed in a list which was limited to 8 entries. This limit can be too small in some cases: by having the same limit as the number of subflows, it might not allow creating all expected subflows when having a mix of v4 and v6 addresses that can all use MPTCP on v4/v6 only networks. While increasing the limit above the new subflows one, why not using the technical limit: 255. Indeed, the endpoint will each have an ID that will be used on the wire, limited to u8, and the ID 0 is reserved to the initial subflow. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_kernel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index ea3a7ea82013..4ba4346d7adc 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -746,7 +746,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_= nl_pernet *pernet, */ if (pernet->next_id =3D=3D MPTCP_PM_MAX_ADDR_ID) pernet->next_id =3D 1; - if (pernet->endpoints >=3D MPTCP_PM_ADDR_MAX) { + if (pernet->endpoints =3D=3D MPTCP_PM_MAX_ADDR_ID) { ret =3D -ERANGE; goto out; } --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 39B6A413236; Fri, 8 May 2026 17:40:36 +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=1778262040; cv=none; b=nFMeogymOmOfGuA8yX21vGsapaSptc6+r7fScfBz06w4v4jANE5NtMOJK26URGdVsFWd6+J9DTdbBUs22cCqVMb7VeAn6pGxs+WU45d5tIvz/hYWiaTDG4XCAS3eh4tn9fPO2/tMA/VGcucATj21ws1qrQCP8GLxmBIVV6PN+hE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262040; c=relaxed/simple; bh=JEJPS1+boQOCZ53oINqHyPXexdvauP9zSb2cgQldesM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=eN5e/jq281IHHS0Xuk0Z1AV/n3ZP5J0GfI791Xnr1JFIZux4rtP73lZ9Xvmz8jIIBYycBrlBOGy6CFSq7Afcge7ECe2dVVEYrqEzadYcqkajPTOhuDKOYdva0f+0On/z0Y4/6YcWvN2nCLFyjpRaRQ4pVinfsMwiuMXXascM/rQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CaAuDJL4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CaAuDJL4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E48D9C2BCB0; Fri, 8 May 2026 17:40:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262035; bh=JEJPS1+boQOCZ53oINqHyPXexdvauP9zSb2cgQldesM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=CaAuDJL4Fkxkmhwkcrw5a0fb+rhxCsjt9ropvf0UQWrACe3yGt+JBAYU3bj15EBIm WEUg9FaXUgammdTkHTaPR805bM7wzMD55evKzXIKdFTE6K6Li6mObKBZJzcjQup6zW Z35E1iRQ1wGds5Vgmq7KqkYj1g7P/7SNGgHfErf2BaZGKmoVZVWQQ+JYM+ZesvX2Ga CDQ/9bQQk4Gs6QQKso0lgQ7vFuy6AUHuN02jlrQEolIy/4ZFtK1C7P6ytCLO15anek OlmGfIXAVZi9uW01UagtRDmOKbgcJwarhpRXGjKaIBGmw+pqZP2bmvIHjtjJq0R1iO rVpqTQILabIJA== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:50 +0200 Subject: [PATCH net-next 5/8] selftests: mptcp: join: allow changing ifaces nr per test Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-5-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2052; i=matttbe@kernel.org; h=from:subject:message-id; bh=JEJPS1+boQOCZ53oINqHyPXexdvauP9zSb2cgQldesM=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KTCr8y5e/WBr6u4ZC463J85Y63q5dltXVVnQ1KO5J SFSB7fkd5SyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAEzkGxsjw5TYRI+Lzj7bGhMF FvhIpj5/tuGSep+KBWv/Tr5dqs9KZRj+1z9cU64hLjMr7J2E7d2I9L70k4Jvy4s337uYsftyzKd JfAA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 By default, 4 network interfaces are created per subtest in a dedicated net namespace. Each netns has a dedicated pair of v4 and v6 addresses. Future tests will need more. Simply always creating more network interfaces per test will increase the execution time for all other tests, for no other benefits. So now it is possible to change this number only when needed, by setting ifaces_nr when calling 'reset' and 'init_shapers', e.g. ifaces_nr=3D8 reset "Subtest title" ifaces_nr=3D8 init_shapers Note that it might also be interesting to decrease the default value to 2 to reduce the setup time, especially when a debug kernel config is being used. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index beec41f6662a..28da9df797ae 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -63,6 +63,7 @@ unset fastclose unset fullmesh unset speed unset bind_addr +unset ifaces_nr unset join_syn_rej unset join_csum_ns1 unset join_csum_ns2 @@ -146,7 +147,7 @@ init_partial() # ns1eth4 ns2eth4 =20 local i - for i in $(seq 1 4); do + for i in $(seq 1 "${ifaces_nr:-4}"); do ip link add ns1eth$i netns "$ns1" type veth peer name ns2eth$i netns "$n= s2" ip -net "$ns1" addr add 10.0.$i.1/24 dev ns1eth$i ip -net "$ns1" addr add dead:beef:$i::1/64 dev ns1eth$i nodad @@ -165,7 +166,7 @@ init_partial() init_shapers() { local i - for i in $(seq 1 4); do + for i in $(seq 1 "${ifaces_nr:-4}"); do tc -n $ns1 qdisc add dev ns1eth$i root netem rate 20mbit delay 1ms tc -n $ns2 qdisc add dev ns2eth$i root netem rate 20mbit delay 1ms done --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 47E70413220; Fri, 8 May 2026 17:40:38 +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=1778262044; cv=none; b=Azdim5Efj/DJnDryG2MzsSpaAkvrrmp5q+oCcdYvwyrmrIR+rJKwzL9M51sC8xjfSujhWglxJ0zpS4bzezUTvkCe9S7kow3OGNIBQdxVooL8rjIbwWeLuKFeER93aqs51OFx1xnFLA/yp+XXWqeDO6k6SbPxhMXg6WOvNZVAyUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262044; c=relaxed/simple; bh=DCMzHqpNNEb72AP94gQCQfS+gUtiYZvhaMQbUzjl7eY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=LzhnUeqz7gJet9DEGUIdirDheB+UAGVRxVYZsFPYcCb65sbd4B++u/Yf2ZO+ni7w3GmTQcq4y3lY0EAGPJtL7CvMfw55YcXxI5llHBqrt78Y8xUhS7GYSIshPgMbLba62Xp1EyvkA2dKd3vLiWKPYU+TyCAVmxT4C9O6D5jmQPQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=F2CF+L3l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="F2CF+L3l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 494FDC2BCC7; Fri, 8 May 2026 17:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262038; bh=DCMzHqpNNEb72AP94gQCQfS+gUtiYZvhaMQbUzjl7eY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=F2CF+L3llyxvsmMflMfJ7XV6gh0LJ+8yTWhETFLeeBCcjBA/r3QQHw7AxtboHHO+E OIQqUqtLf8VbJC+9coJhHMPUeX3GvX6PDddrCN0aPxxuzHe+2Kzwzg8ddO19KhVYd+ CE+P4xOrMYTIxozQNdr+VpIzi92xOnK2SHcM8xl9TdhP574EMxAC9iWKC/6PfZQeVd 2j3r5w78rYrr4skxk+t02++FwXIrqVVJ6Bkt7wlo+xyhC8/3l4staWtUdnVWGRw0Ot M4uezGoSpScwPBUOnQQypKOVOJeX0AguCnnzU6OXmauTamRqteEJXIBhX9Mh9mfege hjxQO8mLyeeXg== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:51 +0200 Subject: [PATCH net-next 6/8] selftests: mptcp: join: validate 8x8 subflows Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-6-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2288; i=matttbe@kernel.org; h=from:subject:message-id; bh=DCMzHqpNNEb72AP94gQCQfS+gUtiYZvhaMQbUzjl7eY=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KbDw6r8o8pSXCC+xm+H6Y3eIA/8sy8JDPrZbOBe3T 42Vfb6to5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCInJjP84bJMLDgYcm7D//fp SemiItd5o6au5k8IMviZfLDzp3JeJSPDVwfThVsmvi/puXRtxqRPt2PXCotPZZTbKnn8xpGSrgO RvAA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The limits have been recently increased, it is required to validate that having 64 subflows is allowed. Here, both the client and the server have 8 network interfaces. The server has 8 endpoints marked as 'signal' to announce all its v4 addresses. The client also has 8 endpoints, but marked as 'subflow' and 'fullmesh' in order to create 8 subflows to each address announced by the server. This means 63 additional subflows will be created after the initial one. If it is not possible to increase the limits to 64, it means an older kernel version is being used, and the test is skipped. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 28 +++++++++++++++++++++= ++++ 1 file changed, 28 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 28da9df797ae..c6bb345d056b 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -513,6 +513,19 @@ reset_with_tcp_filter() fi } =20 +# For kernel supporting limits above 8 +# $1: title ; $2,4: addrs limit ns1,2 ; $3,5: subflows limit ns1,2 +reset_with_high_limits() +{ + reset "${1}" || return 1 + + if ! pm_nl_set_limits "${ns1}" "${2}" "${3}" 2>/dev/null || + ! pm_nl_set_limits "${ns2}" "${4}" "${5}" 2>/dev/null; then + mark_as_skipped "unable to set the limits to ${*:2}" + return 1 + fi +} + # $1: err msg fail_test() { @@ -3670,6 +3683,21 @@ fullmesh_tests() chk_prio_nr 0 1 1 0 chk_rm_nr 0 1 fi + + # fullmesh in 8x8 to create 63 additional subflows + if ifaces_nr=3D8 reset_with_high_limits "fullmesh 8x8" 64 64 64 64; then + # higher chance to lose ADD_ADDR: allow retransmissions + ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=3D1 + local i + for i in $(seq 1 8); do + pm_nl_add_endpoint $ns2 10.0.$i.2 flags subflow,fullmesh + pm_nl_add_endpoint $ns1 10.0.$i.1 flags signal + done + speed=3Dslow \ + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 63 63 63 + fi + } =20 fastclose_tests() --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 BCD7F413233; Fri, 8 May 2026 17:40:40 +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=1778262040; cv=none; b=Rc6xPbJrKReuqYbYbWVqAOLqrXPxBpMd/pMNzPIa3tlC66XTlyd5sszlYZsAgy1O42n4W+3PI6oxyZv0IIt5eJsWLFjAKv8Mio4/QAD245Ots1JrMjLudzNicV/Z/E9wfzTDcKFo4E+YUcHIVmPGeAHRPG8Yx+ixS+EOw9i9ckE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262040; c=relaxed/simple; bh=5FVfWYuoGz0Zn8Q8SR3RXtzYK9TljuG6iDQtTi1S4Rw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bLTbh8eJeeplyXSApTfhZZn8jajd+v5MX7DRsvrAww0Q2rtmQ4UxL+celiyvUSQw4DvxyLGYE36zZdhI1qUOtdhHr6EnoU7g+/8aXeihK7xYjh0WqvYVGrmzgWZqgLC7D6E6GflAh16fIClu8rbwS2cg+9JDm8R1eSNduirl0tc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XsmaZYqU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XsmaZYqU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2B8AC2BCF4; Fri, 8 May 2026 17:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262040; bh=5FVfWYuoGz0Zn8Q8SR3RXtzYK9TljuG6iDQtTi1S4Rw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=XsmaZYqUGADB8RL34v86lYYhQZvJqQSqBskMhPYDmMDYXmBI2q4B2KamHZxqnyLlN 1tlVxOMJRbaV96OeWOsL/2Fq8Rv6oYH/NAq+yydj4zIwzebfu/lKdg7oTXMNvXsV7E haHY6d2l8o0pe0XGRnEMtOsKKsObayF7PQfteTdC9Zp8vrvPQgFUB7TEAFd1g8+24T xurwuySHsAKyhIuX6TaS70kNiRRHcKozLA/qynYwp+tWHZhy51ZpstKWbQORYWLv5N FMQs5a5npmdib1TYdVKIPsD2DXNTKchExnNchFt0uCV4Mwj+N5NAxC6twbDLkcbWsk mPiiXnzfPovoA== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:52 +0200 Subject: [PATCH net-next 7/8] selftests: mptcp: pm: validate new limits Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-7-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3863; i=matttbe@kernel.org; h=from:subject:message-id; bh=5FVfWYuoGz0Zn8Q8SR3RXtzYK9TljuG6iDQtTi1S4Rw=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KbAyLtr9ebpv9ua/ZyZWPL8mJbRkc5/S9bp5wgoL4 2KtBeU2dpSyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAExEIJ6R4fY+hnvf94fOfKO1 e8U5rftLF2w/tvykT+du4b+Ped0DQ9wY/hkI2Lru15/KIFzB6ZF19lfWZT4mpeRTz2x+Vy9crK3 8kRcA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 These limits have been recently updated, from 8 to: - 64 for the subflows and accepted add_addr - 255 for the MPTCP endpoints These modifications validate the new limits, but are also compatible with the previous ones, to be able to continue to validate stable kernel using the last version of the selftests. That's why new variables are now used instead of hard-coded values. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/pm_netlink.sh | 56 +++++++++++++++------= ---- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/pm_netlink.sh b/tools/testin= g/selftests/net/mptcp/pm_netlink.sh index 04594dfc22b1..21bfe1311f11 100755 --- a/tools/testing/selftests/net/mptcp/pm_netlink.sh +++ b/tools/testing/selftests/net/mptcp/pm_netlink.sh @@ -66,6 +66,15 @@ get_limits() { fi } =20 +get_limits_nb() { + if mptcp_lib_is_ip_mptcp; then + ip -n "${ns1}" mptcp limits | awk '{ print $2" "$4 }' + else + ip netns exec "${ns1}" ./pm_nl_ctl limits | \ + awk '{ printf "%s ", $2 }' + fi +} + format_endpoints() { mptcp_lib_pm_nl_format_endpoints "${@}" } @@ -164,6 +173,7 @@ check "get_endpoint 2" "" "simple del addr" 1 check "show_endpoints" \ "$(format_endpoints "1,10.0.1.1" \ "3,10.0.1.3,signal backup")" "dump addrs after del" +add_endpoint 10.0.1.2 id 2 =20 add_endpoint 10.0.1.3 2>/dev/null check "get_endpoint 4" "" "duplicate addr" 1 @@ -171,25 +181,29 @@ check "get_endpoint 4" "" "duplicate addr" 1 add_endpoint 10.0.1.4 flags signal check "get_endpoint 4" "$(format_endpoints "4,10.0.1.4,signal")" "id addr = increment" =20 -for i in $(seq 5 9); do - add_endpoint "10.0.1.${i}" flags signal >/dev/null 2>&1 -done -check "get_endpoint 9" "$(format_endpoints "9,10.0.1.9,signal")" "hard add= r limit" -check "get_endpoint 10" "" "above hard addr limit" 1 +read -r -a default_limits_nb <<< "$(get_limits_nb)" +# limits have been increased: from 8 to 64 for subflows/add_addr & 255 for= endp +if mptcp_lib_expect_all_features || set_limits 9 9 2>/dev/null; then + max_endp=3D255 + max_limits=3D64 +else + max_endp=3D8 + max_limits=3D8 +fi +set_limits "${default_limits_nb[@]}" =20 -del_endpoint 9 -for i in $(seq 10 255); do - add_endpoint 10.0.0.9 id "${i}" - del_endpoint "${i}" +for i in $(seq 5 ${max_endp}); do + add_endpoint "10.0.0.${i}" id "${i}" done -check "show_endpoints" \ - "$(format_endpoints "1,10.0.1.1" \ - "3,10.0.1.3,signal backup" \ - "4,10.0.1.4,signal" \ - "5,10.0.1.5,signal" \ - "6,10.0.1.6,signal" \ - "7,10.0.1.7,signal" \ - "8,10.0.1.8,signal")" "id limit" +check "get_endpoint ${max_endp}" \ + "$(format_endpoints "${max_endp},10.0.0.${max_endp}")" "id limit" + +if add_endpoint '10.0.0.1' &>/dev/null; then + hardlimit=3D"no error" +else + hardlimit=3D"error" +fi +check "echo ${hardlimit}" "error" "above hard addr limit" =20 flush_endpoint check "show_endpoints" "" "flush addrs" @@ -202,15 +216,15 @@ if ! mptcp_lib_is_ip_mptcp; then flush_endpoint fi =20 -set_limits 9 1 2>/dev/null +set_limits $((max_limits + 1)) 1 2>/dev/null check "get_limits" "${default_limits}" "rcv addrs above hard limit" =20 -set_limits 1 9 2>/dev/null +set_limits 1 $((max_limits + 1)) 2>/dev/null check "get_limits" "${default_limits}" "subflows above hard limit" =20 -set_limits 8 8 +set_limits ${max_limits} ${max_limits} flush_endpoint ## to make sure it doesn't affect the limits -check "get_limits" "$(format_limits 8 8)" "set limits" +check "get_limits" "$(format_limits ${max_limits} ${max_limits})" "set lim= its" =20 flush_endpoint add_endpoint 10.0.1.1 --=20 2.53.0 From nobody Mon May 25 03:35:40 2026 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 63D19421EEB; Fri, 8 May 2026 17:40:43 +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=1778262045; cv=none; b=KX8LWU41VCn8Qw6HDyw9CeVzm+hCq2N4fD0+TiXbTlDplu5r8m2yT3YPCHWIOMy9w05OYfxg4VWxSZZNGEzsfvtgDPNJAAUqZTjklZF31KIs5aWgAk++6C8XTcT20ZJxavqBwcHIIuXpH5fPfbKDrer8pgrOEvtDtjsLYV3Fil0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262045; c=relaxed/simple; bh=325C5AQXZLCkra1M3X28PDkJPHJO5DOfdGSOM4n3fqI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=QZw4YAq1foBMnChiQIOzR2u2cg070PwV9xor7szHsavajiazM9cjyu5B6hYXYihbwegjIFtd1IOc2y9brTXwOHUppRXB4mAuxa1ROKTaRdakr+w+s0OpoHBspO51kbfWVhQBkDHE2hD9hxKfR6y9TcbQZJn3k72F0rRzP7edkbc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RxsXy9OU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RxsXy9OU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07D9CC2BCB0; Fri, 8 May 2026 17:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778262043; bh=325C5AQXZLCkra1M3X28PDkJPHJO5DOfdGSOM4n3fqI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=RxsXy9OUY3PKH34jfATIN07hmB8BvAvUgeS6Ipi/VG+8jKX/iiNOh6hMXAUJcU4v/ 344KFqM50FSM0UuypiQYqhhiTze2NXoSTEKMs2qUcCWI+SRTd85vQijx1q3cf2KNGT qXa/cRD01lt48m3LDeeEBgxBe4KpehrvUtLfq/Xk4/Eiu9lWyxh0pFYqDSOP2Y8lMm kxQ0eathffirhwC+qb24dBvSc4/1Ot+Ew2GVOKc7RWrd07W+EEuCGbdoqfjIYWaUDm n9W1//nhtj3pKCZPnPys8/CrpYMXykilidHEk7LyLYsYhbVvPksHh7lkyTcFpgt0tQ +7JHB1Fq4Z7SA== From: "Matthieu Baerts (NGI0)" Date: Fri, 08 May 2026 17:40:53 +0200 Subject: [PATCH net-next 8/8] selftests: mptcp: pm: use simpler send/recv forms Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260508-net-next-mptcp-pm-inc-limits-v1-8-c84e3fdf9b6a@kernel.org> References: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> In-Reply-To: <20260508-net-next-mptcp-pm-inc-limits-v1-0-c84e3fdf9b6a@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1856; i=matttbe@kernel.org; h=from:subject:message-id; bh=325C5AQXZLCkra1M3X28PDkJPHJO5DOfdGSOM4n3fqI=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDL/KbC1n7UOl00PbwpT5Na99bIo5ojLYW/V9N4IB4PtR X9msj7oKGVhEONikBVTZJFui8yf+byKt8TLzwJmDisTyBAGLk4BmMjs6Qz/FGyECj0OfZ2o/8d+ 30Svjb7aNbs3bjhSc9rc6UfjXoGrpowMZ15sd5v6ynQy86orqcdPTJKzvf7tjsk/91TRvbW/4q3 1uAE= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Instead of sendto() and recvfrom() which the NL address that was already provided before. Just simpler and easier to read without the to/from variants. While at it, fix a checkpatch warning by removing multiple assignments. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/pm_nl_ctl.c b/tools/testing/= selftests/net/mptcp/pm_nl_ctl.c index 99eecccbf0c8..78180da1efcc 100644 --- a/tools/testing/selftests/net/mptcp/pm_nl_ctl.c +++ b/tools/testing/selftests/net/mptcp/pm_nl_ctl.c @@ -217,8 +217,6 @@ static int capture_events(int fd, int event_group) /* do a netlink command and, if max > 0, fetch the reply ; nh's size >1024= B */ static int do_nl_req(int fd, struct nlmsghdr *nh, int len, int max) { - struct sockaddr_nl nladdr =3D { .nl_family =3D AF_NETLINK }; - socklen_t addr_len; void *data =3D nh; int rem, ret; int err =3D 0; @@ -230,15 +228,15 @@ static int do_nl_req(int fd, struct nlmsghdr *nh, int= len, int max) } =20 nh->nlmsg_len =3D len; - ret =3D sendto(fd, data, len, 0, (void *)&nladdr, sizeof(nladdr)); + ret =3D send(fd, data, len, 0); if (ret !=3D len) error(1, errno, "send netlink: %uB !=3D %uB\n", ret, len); =20 - addr_len =3D sizeof(nladdr); - rem =3D ret =3D recvfrom(fd, data, max, 0, (void *)&nladdr, &addr_len); + ret =3D recv(fd, data, max, 0); if (ret < 0) error(1, errno, "recv netlink: %uB\n", ret); =20 + rem =3D ret; /* Beware: the NLMSG_NEXT macro updates the 'rem' argument */ for (; NLMSG_OK(nh, rem); nh =3D NLMSG_NEXT(nh, rem)) { if (nh->nlmsg_type =3D=3D NLMSG_DONE) --=20 2.53.0