From nobody Sun Mar 22 08:27:53 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 AF7C53C6A39; Tue, 3 Mar 2026 10:56:30 +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=1772535390; cv=none; b=sJMRrzcuez6f00TS9nShvs6SZLwLPAstZe6igbnAGYkstWECOw5NAywIlE1gBte9/Hl3uwVcPEkwFFOULRLzQbkq1kRKwdTinSHGCmmpF1YdUf/KUj3UxFm1pLrhzPxnpCuP3p5ck2AyOTHImlIa4hsW4OZlqaJK+lQ1iFLgdYM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772535390; c=relaxed/simple; bh=Ks5sz/Z+ErNwuPM92DKF6giNHn/EWfQ89oX63UDnp4Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=EfAXX8oKr7qdWap4/AGtMp2/vxqW0YlD5ZLOrbqa0yu4DZQGb77155Ks6w38O7O4z2eIm5MZxVWcfZRIcOtkWvapgaUDvO46Z2Mv40MnL+fmwws+KJOd2CeMRAoSj9HWiWSTwsdx1/RWGklnRyW4fqimFQHwBlf0ZJvIQ1cpQyI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cWt6LZ5f; 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="cWt6LZ5f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E65DBC2BC9E; Tue, 3 Mar 2026 10:56:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772535390; bh=Ks5sz/Z+ErNwuPM92DKF6giNHn/EWfQ89oX63UDnp4Y=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=cWt6LZ5fc1lbMOIuKFrnj+BeakCCdQyYEzVjlKBJjqoHUKTuW6e+ZDqmPNL8/pyi/ 0Ktj1KtBIaFmS5LXp7OeJKVXjaJpdnbAZGxPdNVF8aJm+jxA4ANjE8z67dFlziNesJ bdR2l5nq54zlUihOicv8Mqz+uvs7dSw/jAMXx8O/12EIl3ExzJt11mtji8/Eu/RrOd UeasLL0j2Oj1GeFxN/qlpgHoYk+88WjSx44ABSqRLszSIEF4aDo+U6dmRk3+OkcuIG /BOi1jeiocd9cx8jZyLG+Bqa9j6iuO4gimxKlkuQY4eTYp+Q2Y7o8texPxftFQmfqO pm7Ogqo5thv9g== From: "Matthieu Baerts (NGI0)" Date: Tue, 03 Mar 2026 11:56:02 +0100 Subject: [PATCH net 1/5] selftests: mptcp: more stable simult_flows tests 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: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-1-4b5462b6f016@kernel.org> References: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> In-Reply-To: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=2606; i=matttbe@kernel.org; h=from:subject:message-id; bh=18tA02xe0nsbth02mlcKtrTHUJ7V+JsHWaPsJEewHgo=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDKX7QswiXGfU7NC5fISqddhXQzrV/z8qlfzU0lxQ7dnw b+vD5/e6ihlYRDjYpAVU2SRbovMn/m8irfEy88CZg4rE8gQBi5OAZjI/48Mf8W/xxgd1nE7dTX8 wv3ojjepE2Sd798+ny5UYzFx35rZk+YyMjTLsZeXpnSv4OPYcu2FwePsRTW5yte5HVMUYlxnX5z EwgoA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni By default, the netem qdisc can keep up to 1000 packets under its belly to deal with the configured rate and delay. The simult flows test-case simulates very low speed links, to avoid problems due to slow CPUs and the TCP stack tend to transmit at a slightly higher rate than the (virtual) link constraints. All the above causes a relatively large amount of packets being enqueued in the netem qdiscs - the longer the transfer, the longer the queue - producing increasingly high TCP RTT samples and consequently increasingly larger receive buffer size due to DRS. When the receive buffer size becomes considerably larger than the needed size, the tests results can flake, i.e. because minimal inaccuracy in the pacing rate can lead to a single subflow usage towards the end of the connection for a considerable amount of data. Address the issue explicitly setting netem limits suitable for the configured link speeds and unflake all the affected tests. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/simult_flows.sh | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/test= ing/selftests/net/mptcp/simult_flows.sh index 806aaa7d2d61..d11a8b949aab 100755 --- a/tools/testing/selftests/net/mptcp/simult_flows.sh +++ b/tools/testing/selftests/net/mptcp/simult_flows.sh @@ -237,10 +237,13 @@ run_test() for dev in ns2eth1 ns2eth2; do tc -n $ns2 qdisc del dev $dev root >/dev/null 2>&1 done - tc -n $ns1 qdisc add dev ns1eth1 root netem rate ${rate1}mbit $delay1 - tc -n $ns1 qdisc add dev ns1eth2 root netem rate ${rate2}mbit $delay2 - tc -n $ns2 qdisc add dev ns2eth1 root netem rate ${rate1}mbit $delay1 - tc -n $ns2 qdisc add dev ns2eth2 root netem rate ${rate2}mbit $delay2 + + # keep the queued pkts number low, or the RTT estimator will see + # increasing latency over time. + tc -n $ns1 qdisc add dev ns1eth1 root netem rate ${rate1}mbit $delay1 lim= it 50 + tc -n $ns1 qdisc add dev ns1eth2 root netem rate ${rate2}mbit $delay2 lim= it 50 + tc -n $ns2 qdisc add dev ns2eth1 root netem rate ${rate1}mbit $delay1 lim= it 50 + tc -n $ns2 qdisc add dev ns2eth2 root netem rate ${rate2}mbit $delay2 lim= it 50 =20 # time is measured in ms, account for transfer size, aggregated link speed # and header overhead (10%) --=20 2.51.0 From nobody Sun Mar 22 08:27:53 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 4303F3C6A38; Tue, 3 Mar 2026 10:56:32 +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=1772535393; cv=none; b=PjLo3Vn/oIz3u88VQot6DSPuzVjkcsKecWK9oUczxA9MVwKSKwhAIJaS8ucvQsBjYPF5vliR/Yn0Y6MXCc2EJukh9m86ebTHgWRoQfiUtVCKwhWTfcCIJyi15/FTLCiNoO5AFhNPova0dc03904F3SduQSxdUuy0PL4Z0MeY9pc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772535393; c=relaxed/simple; bh=B5z+KFhPcJgXrbHNEA47/crWzvwpnRXOTRs7q3iRcvQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SmakifbC9ScKEwyFURnsrumzEqHAIM4tijsdXtf796YZkwp0WIDMMDzpUODx9rl01yCSe6GIOG/yeFoZ7/aFItq627X5qG5KiiqrKU8cSswQbecM3IMy5J7DUFosCtJz+czUQAE+2IQ0l0R46ozCWvQNg954mkdZ9X9tgMycaq0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZVBlOtns; 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="ZVBlOtns" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7997FC2BCAF; Tue, 3 Mar 2026 10:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772535392; bh=B5z+KFhPcJgXrbHNEA47/crWzvwpnRXOTRs7q3iRcvQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ZVBlOtnsUMPDAs6I6F1/i5cmGiL2gvN+AhZZWDL9dXq6522ssqXi8O2KQRelUbROE ri5fykPoprgoZ4O4q/BDBRbxfIgPEMxvNCeXqByceTVoafaQCm3XQekDtl1stW+KLR 8BO2t7gpyyky9fQP1Ql71dJzlAt5DmAuwTuFC1z40C/vruaWD2Wa8AbBP4WABryjfh Tyd9pBPYa00FWBzisAMiByPYgO1hRbNU8dl+OOi8a+Cxxe10CP0hgYHPOQtsdquwMc m7cxfaxE4XVdt93994fq7XGwZ+ca7alZKXq0zqq/1wlUgPJG1p6dE+h6kevM8+9J2I WI75v7k1PJrkw== From: "Matthieu Baerts (NGI0)" Date: Tue, 03 Mar 2026 11:56:03 +0100 Subject: [PATCH net 2/5] mptcp: pm: avoid sending RM_ADDR over same subflow 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: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-2-4b5462b6f016@kernel.org> References: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> In-Reply-To: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Frank Lorenz X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3512; i=matttbe@kernel.org; h=from:subject:message-id; bh=B5z+KFhPcJgXrbHNEA47/crWzvwpnRXOTRs7q3iRcvQ=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDKX7QvqNAktqJRWKfSu3OVo6Mb23PLWz9PXVHTrGf1Fu V4EJt3rKGVhEONikBVTZJFui8yf+byKt8TLzwJmDisTyBAGLk4BmIhPEcM/peN54lueXTe4mf5b VL7le3X6W+7I6KmTYiLe7snJ+HNrA8P/8JtHHs+05u80btpgvFNj1jx+54p/Nun8Qb1fezelJIr wAgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 RM_ADDR are sent over an active subflow, the first one in the subflows list. There is then a high chance the initial subflow is picked. With the in-kernel PM, when an endpoint is removed, a RM_ADDR is sent, then linked subflows are closed. This is done for each active MPTCP connection. MPTCP endpoints are likely removed because the attached network is no longer available or usable. In this case, it is better to avoid sending this RM_ADDR over the subflow that is going to be removed, but prefer sending it over another active and non stale subflow, if any. This modification avoids situations where the other end is not notified when a subflow is no longer usable: typically when the endpoint linked to the initial subflow is removed, especially on the server side. Fixes: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reported-by: Frank Lorenz Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/612 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 55 +++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 43 insertions(+), 12 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 7298836469b3..57a456690406 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -212,9 +212,24 @@ void mptcp_pm_send_ack(struct mptcp_sock *msk, spin_lock_bh(&msk->pm.lock); } =20 -void mptcp_pm_addr_send_ack(struct mptcp_sock *msk) +static bool subflow_in_rm_list(const struct mptcp_subflow_context *subflow, + const struct mptcp_rm_list *rm_list) { - struct mptcp_subflow_context *subflow, *alt =3D NULL; + u8 i, id =3D subflow_get_local_id(subflow); + + for (i =3D 0; i < rm_list->nr; i++) { + if (rm_list->ids[i] =3D=3D id) + return true; + } + + return false; +} + +static void +mptcp_pm_addr_send_ack_avoid_list(struct mptcp_sock *msk, + const struct mptcp_rm_list *rm_list) +{ + struct mptcp_subflow_context *subflow, *stale =3D NULL, *same_id =3D NULL; =20 msk_owned_by_me(msk); lockdep_assert_held(&msk->pm.lock); @@ -224,19 +239,35 @@ void mptcp_pm_addr_send_ack(struct mptcp_sock *msk) return; =20 mptcp_for_each_subflow(msk, subflow) { - if (__mptcp_subflow_active(subflow)) { - if (!subflow->stale) { - mptcp_pm_send_ack(msk, subflow, false, false); - return; - } + if (!__mptcp_subflow_active(subflow)) + continue; =20 - if (!alt) - alt =3D subflow; + if (unlikely(subflow->stale)) { + if (!stale) + stale =3D subflow; + } else if (unlikely(rm_list && + subflow_in_rm_list(subflow, rm_list))) { + if (!same_id) + same_id =3D subflow; + } else { + goto send_ack; } } =20 - if (alt) - mptcp_pm_send_ack(msk, alt, false, false); + if (same_id) + subflow =3D same_id; + else if (stale) + subflow =3D stale; + else + return; + +send_ack: + mptcp_pm_send_ack(msk, subflow, false, false); +} + +void mptcp_pm_addr_send_ack(struct mptcp_sock *msk) +{ + mptcp_pm_addr_send_ack_avoid_list(msk, NULL); } =20 int mptcp_pm_mp_prio_send_ack(struct mptcp_sock *msk, @@ -470,7 +501,7 @@ int mptcp_pm_remove_addr(struct mptcp_sock *msk, const = struct mptcp_rm_list *rm_ msk->pm.rm_list_tx =3D *rm_list; rm_addr |=3D BIT(MPTCP_RM_ADDR_SIGNAL); WRITE_ONCE(msk->pm.addr_signal, rm_addr); - mptcp_pm_addr_send_ack(msk); + mptcp_pm_addr_send_ack_avoid_list(msk, rm_list); return 0; } =20 --=20 2.51.0 From nobody Sun Mar 22 08:27:53 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 C43DA3CC9EB; Tue, 3 Mar 2026 10:56:35 +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=1772535395; cv=none; b=EMJgJKLTTSAEG2vI3OjPwzokRTFlKGsAls997oMlnaGWoH6rmrCmdcbxgxdp5WXZIreDjhyq2JEAlCNs7XNfUiSkY1DZ/88d9z87jEvWfeSdA4bwPPHk65frgFkkCeWVI7FPWDRbLjAlNIOM3AeXb/DnUCUyrr3XoSrJu5T6rQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772535395; c=relaxed/simple; bh=FFMlO/2VSIT4Y74XGRmhekzQB204Lkh4fCnE8YpYa8M=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=eteRKo9cFIr7E27UWiJqaQoRD8/imUvbeF12AYQYVVE7WVEVmyGwfETBvCW6i9oSdeHtcTZE0qiB397hqGG1qFDWdocpcq3v4znqQpp0h45GNHpABSJ2JNSXWdunw+8jNKIrhqRjgW6a9kC+frgulTJOcWID3rBS8duVnZQXcE8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zu8lvysj; 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="Zu8lvysj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F578C2BC9E; Tue, 3 Mar 2026 10:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772535395; bh=FFMlO/2VSIT4Y74XGRmhekzQB204Lkh4fCnE8YpYa8M=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Zu8lvysjTi4lDp0yFcSrSBKnPMPILaESMMpFodfNakkt5Etk3ef296BP0spi+JdOx E1W/2ZeHK4KZTWYJmnhZGOlklP2aN5qLSuB4TiW/fUsDlJ7jaoxfNraLtahLQwGXuy LvsdpJ9I7R/TQpb/mY5wjmaRhJDmmefK/qyhs5V84kOPYg8Sf9yz8vUfT68vBvzmdp P27tNypWVUVlk/BnheGZbm/NfenvFX3v96j4oo2WntXBMfwlpEqHy2BaLDcS41Gw/8 EzO8WIZ2HCnIkVG5Q6q2ICSamyY+CEV8vFyXh6dPG9hzAd5sbBcdMM31zWkidPBsd9 rOql4FF1uW/RQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 03 Mar 2026 11:56:04 +0100 Subject: [PATCH net 3/5] selftests: mptcp: join: check RM_ADDR not sent over same subflow 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: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-3-4b5462b6f016@kernel.org> References: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> In-Reply-To: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3877; i=matttbe@kernel.org; h=from:subject:message-id; bh=FFMlO/2VSIT4Y74XGRmhekzQB204Lkh4fCnE8YpYa8M=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDKX7Qv5zLm3bZP5FPeNLzo1b8wTZw6Z4pF78NiRszO4T heXTFoxu6OUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAiS00YGV7GTJT2NFootOKs XsGnxMxiWd4M7vi34Y5BU27GPb0qGsXwv+xzlMD2i0run11VWhUvytiXvY2evTtkHU9KfF5Kvkg kNwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 This validates the previous commit: RM_ADDR were sent over the first found active subflow which could be the same as the one being removed. It is more likely to loose this notification. For this check, RM_ADDR are explicitly dropped when trying to send them over the initial subflow, when removing the endpoint attached to it. If it is dropped, the test will complain because some RM_ADDR have not been received. Note that only the RM_ADDR are dropped, to allow the linked subflow to be quickly and cleanly closed. To only drop those RM_ADDR, a cBPF byte code is used. If the IPTables commands fail, that's OK, the tests will continue to pass, but not validate this part. This can be ignored: another subtest fully depends on such command, and will be marked as skipped. 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: 8dd5efb1f91b ("mptcp: send ack for rm_addr") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 36 +++++++++++++++++++++= ++++ 1 file changed, 36 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index dc1f200aaa81..058ad5a13d24 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -104,6 +104,24 @@ CBPF_MPTCP_SUBOPTION_ADD_ADDR=3D"14, 6 0 0 65535, 6 0 0 0" =20 +# IPv4: TCP hdr of 48B, a first suboption of 12B (DACK8), the RM_ADDR subo= ption +# generated using "nfbpf_compile '(ip[32] & 0xf0) =3D=3D 0xc0 && ip[53] = =3D=3D 0x0c && +# (ip[66] & 0xf0) =3D=3D 0x40'" +CBPF_MPTCP_SUBOPTION_RM_ADDR=3D"13, + 48 0 0 0, + 84 0 0 240, + 21 0 9 64, + 48 0 0 32, + 84 0 0 240, + 21 0 6 192, + 48 0 0 53, + 21 0 4 12, + 48 0 0 66, + 84 0 0 240, + 21 0 1 64, + 6 0 0 65535, + 6 0 0 0" + init_partial() { capout=3D$(mktemp) @@ -4217,6 +4235,14 @@ endpoint_tests() chk_subflow_nr "after no reject" 3 chk_mptcp_info subflows 2 subflows 2 =20 + # To make sure RM_ADDR are sent over a different subflow, but + # allow the rest to quickly and cleanly close the subflow + local ipt=3D1 + ip netns exec "${ns2}" ${iptables} -I OUTPUT -s "10.0.1.2" \ + -p tcp -m tcp --tcp-option 30 \ + -m bpf --bytecode \ + "$CBPF_MPTCP_SUBOPTION_RM_ADDR" \ + -j DROP || ipt=3D0 local i for i in $(seq 3); do pm_nl_del_endpoint $ns2 1 10.0.1.2 @@ -4229,6 +4255,7 @@ endpoint_tests() chk_subflow_nr "after re-add id 0 ($i)" 3 chk_mptcp_info subflows 3 subflows 3 done + [ ${ipt} =3D 1 ] && ip netns exec "${ns2}" ${iptables} -D OUTPUT 1 =20 mptcp_lib_kill_group_wait $tests_pid =20 @@ -4288,11 +4315,20 @@ endpoint_tests() chk_mptcp_info subflows 2 subflows 2 chk_mptcp_info add_addr_signal 2 add_addr_accepted 2 =20 + # To make sure RM_ADDR are sent over a different subflow, but + # allow the rest to quickly and cleanly close the subflow + local ipt=3D1 + ip netns exec "${ns1}" ${iptables} -I OUTPUT -s "10.0.1.1" \ + -p tcp -m tcp --tcp-option 30 \ + -m bpf --bytecode \ + "$CBPF_MPTCP_SUBOPTION_RM_ADDR" \ + -j DROP || ipt=3D0 pm_nl_del_endpoint $ns1 42 10.0.1.1 sleep 0.5 chk_subflow_nr "after delete ID 0" 2 chk_mptcp_info subflows 2 subflows 2 chk_mptcp_info add_addr_signal 2 add_addr_accepted 2 + [ ${ipt} =3D 1 ] && ip netns exec "${ns1}" ${iptables} -D OUTPUT 1 =20 pm_nl_add_endpoint $ns1 10.0.1.1 id 99 flags signal wait_mpj 4 --=20 2.51.0 From nobody Sun Mar 22 08:27:53 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 B50B63CD8B4; Tue, 3 Mar 2026 10:56: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=1772535398; cv=none; b=JN96FUytStICyVptPjmMVfxic45OZmdtVyfsiz2Yv3n1YddPBaSx7ma9/fjcF5O+cdmkKqC277Na5NDxMoS+7kQyvm0NRD+lQt7RuftApUQpYY2DFGhELFfYDmIHdNDrOjPcrsfTpnFQ+1DNKQTUIdkK89GCooRQBIUJpg2obWA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772535398; c=relaxed/simple; bh=UsDZdbqrdtQSAlydqaqVZ55wtdSN6p2vnSmREhIxL64=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=mkulTxv1CiZZRxn3Iivme3yDScMf768XGR9Dza6G577y1kG4nORN5C4QpuEgiobF9k9fmIqprXt5pzbsLnnF64ZYMEbw3ZD9Z5tv+b0NYyIo70+Avkq7Nz1nszymhyOUTFBAE0oHkZM94prC1w/pWE0ixWQ55CEFR2allnd8KkA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ieoaLqkm; 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="ieoaLqkm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBDDDC4AF0D; Tue, 3 Mar 2026 10:56:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772535398; bh=UsDZdbqrdtQSAlydqaqVZ55wtdSN6p2vnSmREhIxL64=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ieoaLqkmfq0CvfSV2BUGOqWtN7/Q/rthq6Ca784kmG0eO21RpKqd3d2iIW9Kc4iPP K0u8SVj09iZ91tgQWEHnTbLF5cv3yYp9aDe9IC12G9wa971ZCyl1UKFIgQRmo5Rsry IvPGOR71Zwpie53kZg0dV4tRMBmNyTUFPmvP/XILGS7Z2Vm6DrMkIxi5e5utyGrOFV wD1zzIp3lnOImkI14L0tHmonqkyzQDr2e2vZ1N/cwduzL04xa3EpEk2o8DgjvEnVVZ gVonbjVzjDJZb1nhV/RTU9l5PlEwzWeezC1NnQu43fopmXahj/wh3abuaC6l1Fg5LJ CWERu8MhJvBNQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 03 Mar 2026 11:56:05 +0100 Subject: [PATCH net 4/5] mptcp: pm: in-kernel: always mark signal+subflow endp as used 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: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-4-4b5462b6f016@kernel.org> References: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> In-Reply-To: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=6091; i=matttbe@kernel.org; h=from:subject:message-id; bh=UsDZdbqrdtQSAlydqaqVZ55wtdSN6p2vnSmREhIxL64=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDKX7QuvYJFeMk2cbSt7ukJq2kN/rq/aZ99ZGC9bt0Pr+ svrr7WndJSyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAEykjInhD8/sqwsD1MQ5PjzI fzBPpuAVQ47pxN8/Tma9C2opkzKKdWBkOCNSuN+l6uCv7eE5stJmG1TTvig0G6gKi6zMurls66c GNgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Syzkaller managed to find a combination of actions that was generating this warning: msk->pm.local_addr_used =3D=3D 0 WARNING: net/mptcp/pm_kernel.c:1071 at __mark_subflow_endp_available net/= mptcp/pm_kernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_nl_remove_subflow_and_signal= _addr net/mptcp/pm_kernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pm_kernel.c:1071 at mptcp_pm_nl_del_addr_doit+0x81d/0x= 8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b= 06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 19= 96), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_kernel.c:1071 [inlin= e] RIP: 0010:mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_kernel.c:1= 103 [inline] RIP: 0010:mptcp_pm_nl_del_addr_doit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 8= 9 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d= ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000= 000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: genl_family_rcv_msg_doit+0x117/0x180 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x16d/0x240 net/netlink/af_netlink.c:2550 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x3e9/0x4c0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x4aa/0x5b0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __do_sys_sendmsg net/socket.c:2683 [inline] __se_sys_sendmsg net/socket.c:2681 [inline] __x64_sys_sendmsg+0x110/0x1a0 net/socket.c:2681 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x143/0x440 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f= 7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff= ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 The actions that caused that seem to be: - Set the MPTCP subflows limit to 0 - Create an MPTCP endpoint with both the 'signal' and 'subflow' flags - Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag) - Remove the MPTCP endpoint In this case, msk->pm.local_addr_used has been kept to 0 -- because no subflows have been created -- but the corresponding bit in msk->pm.id_avail_bitmap has been cleared when the ADD_ADDR has been sent. This later causes a splat when removing the MPTCP endpoint because msk->pm.local_addr_used has been kept to 0. Now, if an endpoint has both the signal and subflow flags, but it is not possible to create subflows because of the limits or the c-flag case, then the local endpoint counter is still incremented: the endpoint is used at the end. This avoids issues later when removing the endpoint and calling __mark_subflow_endp_available(), which expects msk->pm.local_addr_used to have been previously incremented if the endpoint was marked as used according to msk->pm.id_avail_bitmap. Note that signal_and_subflow variable is reset to false when the limits and the c-flag case allows subflows creation. Also, local_addr_used is only incremented for non ID0 subflows. Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag i= s also set") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/613 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_kernel.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index b5316a6c7d1b..b2b9df43960e 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -418,6 +418,15 @@ static void mptcp_pm_create_subflow_or_signal_addr(str= uct mptcp_sock *msk) } =20 exit: + /* If an endpoint has both the signal and subflow flags, but it is not + * possible to create subflows -- the 'while' loop body above never + * executed -- then still mark the endp as used, which is somehow the + * case. This avoids issues later when removing the endpoint and calling + * __mark_subflow_endp_available(), which expects the increment here. + */ + if (signal_and_subflow && local.addr.id !=3D msk->mpc_endpoint_id) + msk->pm.local_addr_used++; + mptcp_pm_nl_check_work_pending(msk); } =20 --=20 2.51.0 From nobody Sun Mar 22 08:27:53 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 7AC4B3CB2FC; Tue, 3 Mar 2026 10:56:41 +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=1772535401; cv=none; b=lW2bBg3rz3gZ3t6YEKUfXO1nMf+2eOAA5wf8LNIz99KErFohDrk/LdACc8mnT9qWMuH7SDvS4G1dbCYgTawbJOx0UIAcmv8qJRgMMZCu0HLMqDphhaxfv1D0XUvZ/WgKQ5LaWGy8eVJhF3SirWtEpXpXzWLraRoTUF3HpYjchcc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772535401; c=relaxed/simple; bh=3hIjxPBplMqBbUMZCyZ/eh+tqQIDphwx8R8DneO0OWM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ueWqp3o4XxLURBtUPB4SsrmFxe8TR7JRNHdMiYrNS4A/m+iiML5KbDUal9khK6YZlI4j+1NwARUUsbtsV6TzyjDjEI+JaM8Y1FvjCtj6+IbqEL30iYtEfs6nYHHHvJpNYpAa688TVXwLLcDRPhmYcuzal8602g3PWcXmTTT3kOk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ijI8TL7p; 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="ijI8TL7p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F1FBC2BCB3; Tue, 3 Mar 2026 10:56:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772535400; bh=3hIjxPBplMqBbUMZCyZ/eh+tqQIDphwx8R8DneO0OWM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ijI8TL7pvMYOQTZ8/vo8iKSNIrmdB8c86WQoRavcdg/i6s7431YJlcWsCGvykFpHa kF8MWIDUIgW55B1t0rzM69RvzPAiI/uBQ06HpLEFU4F7Lc5nmh7v0fNzYPww0pB+M0 gKtoPN5ePGcTYQ0ush4kWGXCU2XHqoyD/STCVCA4I/kpng6wrLJoX8pploFx3j3OTw y2JzY8/fUSye0nl3zfVR6gtWnV8z0bKHtjhLm+e+V7i/aFRN7To9xm1cGVkq2GLZSw NmGb8Xsk6JzjUTcMlQiJGCMGDazaz0tR74m1lD0JzaASkgIeU+stqW+6z82ffD5JL9 8Awc5tiTINXLQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 03 Mar 2026 11:56:06 +0100 Subject: [PATCH net 5/5] selftests: mptcp: join: check removing signal+subflow endp 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: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-5-4b5462b6f016@kernel.org> References: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> In-Reply-To: <20260303-net-mptcp-misc-fixes-7-0-rc2-v1-0-4b5462b6f016@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1902; i=matttbe@kernel.org; h=from:subject:message-id; bh=3hIjxPBplMqBbUMZCyZ/eh+tqQIDphwx8R8DneO0OWM=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDKX7YtIPrYwQoSLc4cS/6TlEkmGB64u9X/9paTsy/76p pdR05PLOkpZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACYim83I8CaE/5RiQrtaYt/E 0h7P3E9T3gZM/f34oFmAVqX/zNvatYwM66YdScp3PrzKcPLyBSL2Qg4LJ196cvnIXd7ErbP07oj 84gIA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 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 i= s also set") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- 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/testin= g/selftests/net/mptcp/mptcp_join.sh index 058ad5a13d24..a3144d7298a5 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -2626,6 +2626,19 @@ remove_tests() chk_rst_nr 0 0 fi =20 + # 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=3D-1 speed=3Dslow \ + 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 --=20 2.51.0