From nobody Wed Oct 30 22:11:13 2024 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 0675F1AD9DD; Wed, 31 Jul 2024 11:06:17 +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=1722423977; cv=none; b=gusAW4mYpCUUnLkewQKh5CSE7DwZDdZS+B3SWH8UDUXCaeboe4TzVLuRY4dDJ42LOT4w7r+mZZVcB7+Rsw+wBHKx+feuK77ZQ8YT/AewqmeMdvKEY8nmi21L1YGNWhcOqbX2FURsE//k8ZCyAu9LOghZHQqjhNmanA1iNcyB/G8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423977; c=relaxed/simple; bh=HReNhR43esWLHlb4CxNQ1QPflXcu4lQSD0K4aCKNWIs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=EbKLmvXbH3ENmoaRdKr/kv25EMJGvXUOqgb8EDHBMRKIh1AVHxoswTpQausRL0+05gENmKZ8zR+J5o0KQc46o4AxH2bhNbHc9RMbSqkz1FxOi0WZkt0tiwEzO034NcI3aNaT5BfSCcK72Xrd2vCDUDrqM7Ehq59hq4wSGpq6dEE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D9xJtCy8; 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="D9xJtCy8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A2DEC4AF0F; Wed, 31 Jul 2024 11:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423976; bh=HReNhR43esWLHlb4CxNQ1QPflXcu4lQSD0K4aCKNWIs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=D9xJtCy8xk9/i2NXHzk9lZwVc3/WQtqfTsvCm2gb/MY5Wz2q9WMjKjOq1T1GTfbID UbppDswdOOhJtqqvTDDK2hMi4sbQKt64nIHadKVA3BLSdpBjaN/qfRd7bBf9A7cKdJ M+L33ZCSw2JC4dTLv7WzYus5rNQtEbXx/Oxqik6pArV4uHfHWw3Gp2GoNhWxSQ+0hJ ktwN9pcGFJ6Ti7qF4cP4deVglW/HfZb7LVFi2/VglhybAg3StnbMUDW03QM2leYIIN ISDPXew8dYxEowVjkZ35MICcJgzwQk/4M1/P9GR12VBbogboQV5iaNz+gZHxu1lzqw U5e2yyhIx1zdw== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:53 +0200 Subject: [PATCH net 1/7] mptcp: fully established after ADD_ADDR echo on MPJ 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-1-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1734; i=matttbe@kernel.org; h=from:subject:message-id; bh=HReNhR43esWLHlb4CxNQ1QPflXcu4lQSD0K4aCKNWIs=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqiM1pBE5/gDL3yeaYLb/u3+NUN0lJ1Jm7yD dhr9Bs+Z92JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg c2oDD/4nIN7uKmD8X7TtoUzgqt8I6ERo45qTgx5y97rcK2oMzB3ZHfcpvOM5ym53s9yqGcAWKHK xk9gCsdzlujh4pJ4RORm+629m3CMXJP0GP+SuG7FkW8HLdjOJI1381M4PwMmiUSLGthi+LenJor czET87j8cvXdAiALP5dCeVVJiOfc34obo6eijIkY0g4bP1pwYcyMJtumqQSyzziAj2E2OHhrLOD jEfVj8gITOZdiNzRavJtjgStJAPt8ZJR+0j4amlZGjFHrTcRvg0C47iiC3ZE2OVKvENO8bYvtWp EUCfmFfDl6zjOKxBclu/RFSgq/Cfkbr8MhN2j2dJFqRcZAbPn3Ck9M1JQtzYJPO4XabmCNX0fdG mQ77q+8s59S70/ukgaZIbx6u39WtMTyB8Qu0Am1Kz/FC0LBi3srZe/j6XuCQVyFrm7hwfTzKNoP Dz4EhK3JkEUwdwMLC9V7odvJ8BcgakaaIChMhFm3aWc7FDIcpMTSZJFM6myNcq9GJn/LawGIP8p oeOchGTrr8riNYXtw4Z1JjjEAD6uOfinrV8Co+dw2EXcY3seoa/+dB+Fdv66rzhpNFwQo+GwyF0 wlpbbRxDxCf0Xkhg2d/i8btrCzMbpSShtvqvVYq8I4lT8Wl2PGxYxeFuH63oyDPSLRgocYEdUp5 NWmqh4ruyLARJsw== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Before this patch, receiving an ADD_ADDR echo on the just connected MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was resulting in an MP_RESET. That's because only ACKs with a DSS or ADD_ADDRs without the echo bit were allowed. Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as we are not supposed to send an ADD_ADDR before because it requires to be in full established mode first. For the MP_JOIN 3WHS, that's different: the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo can be received on the recently created one. The other peer will already be in fully established, so it is allowed to send that. We can then relax the conditions here to accept the ADD_ADDR echo for MPJ subflows. Fixes: 67b12f792d5e ("mptcp: full fully established support after ADD_ADDR") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/options.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 8a68382a4fe9..ac2f1a54cc43 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -958,7 +958,8 @@ static bool check_fully_established(struct mptcp_sock *= msk, struct sock *ssk, =20 if (subflow->remote_key_valid && (((mp_opt->suboptions & OPTION_MPTCP_DSS) && mp_opt->use_ack) || - ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && !mp_opt->echo))) { + ((mp_opt->suboptions & OPTION_MPTCP_ADD_ADDR) && + (!mp_opt->echo || subflow->mp_join)))) { /* subflows are fully established as soon as we get any * additional ack, including ADD_ADDR. */ --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 4D5671AE85E; Wed, 31 Jul 2024 11:06:20 +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=1722423980; cv=none; b=n5crIwsjtL/02P+IrQLxmIppqTd3nHBHmwoYYCDeF7qLSz0m1gEd0tURx3QAhWQ+zCa9ia6OYqCsjCtV9OV379soFyB9UQYmnKWchiNEtzgO5IbDyFYQMEgoQjvyh0GAuYS3ITZS36An2/NrVojQGRHIhb8J75cpLBMxBLijVB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423980; c=relaxed/simple; bh=FmkH0+f1Fqx4WtwJID1fgBwuFioKVrOh3mCO/tO4RrU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bMqbEzElKP+ks+2359mpP8VOjxaJrXobzYVG0NvF+Cpe7SNW5u3ClwXLPEJK3EemG8HgcH9o/oHrmEHo7QBPsocXofDuoAQuqqVtKUin2RdtX1LvYZBig7M5F+0Ckldw4HzaVwRkq3hU47INjMuggEXHnu2/vUlkhYUQlgdNe9g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TC4Ulg+E; 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="TC4Ulg+E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DDABC116B1; Wed, 31 Jul 2024 11:06:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423979; bh=FmkH0+f1Fqx4WtwJID1fgBwuFioKVrOh3mCO/tO4RrU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=TC4Ulg+Ep18OVuVjeJqfiIHM+AlZU1WKCBpGwlVjGdHRDSV4I+FKkLOEVQh57HTt1 FRB/zMftzBCFNTVoIJPyXi5ityL6J099RqDuqQubcPovJ9TlVzmdgyF9kcECwMBs27 j3ydHFgDcqQ6W7IyRnKWQKR0PpnJZuXQbMnaabyMdyjpE8li0yPlH1X/df5ZeaEK2G zKTWPQN6BB0/ZzmalygLDYUlQmknPm3lXzN3Y53ZiTBHNvk3aHtcJoZR0p7S65ABK6 C9I4/kp31/fHH/453Ac5/agficbQtZOUZMVFx9vbjVViG7kpS6QSz2nwOGIjMt6v+D 1v3+SPBKiPI3g== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:54 +0200 Subject: [PATCH net 2/7] mptcp: pm: deny endp with signal + subflow + port 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-2-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1468; i=matttbe@kernel.org; h=from:subject:message-id; bh=FmkH0+f1Fqx4WtwJID1fgBwuFioKVrOh3mCO/tO4RrU=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqiivhaBZFFCirPtnI6jP4wm2uKizquuPbib xIyyx1//iWJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg cz/7EACEnXwJ1umzoiyD9o6ZCfopCepktNq5klK8Rk5aNR4qDozgW8JbjVHV0XOgKmlY8BC2/Wk WuWCpcbSVjUzfE1/CcPRXC5XsnNkW0CNByHkUsNW+K+IPzNrvZIIkc1hwuZ50K3Gc0M0AzU2heP 5V+8LKYsGVdtJn6X97cwrp4v8NRricaFB0tgP58QsuOfsYuPDrN5SessXS2j6R9g9DpsCHD1C1o EMDzaPqxIPnUUYjq7wCWIs6fprzwEYfKK9XNN0zHrmAY/OI/DGvOXfrWqeoaC2qPfTK9mWW0He+ ZMo4ef0sZMeaNkFlfDTcl6V5EFK2vBd8fkfDEGkWig6h9/CzuiF3GERIHpddrppjBNwWAvCLQ1Q scQavo/1IjME/xpr92ngC7YdLGN3gySCCeoyjN7JhU7ceEwxhYiIgo9gqLd6bzYtYKfkoYnyTMW Fp+LLhA2pQ+IxhodHyONLV87trUXki/8+ut7kPUi/D9ftZuezDg5nwuuvykUSMJs1ocGornoRuh 4FQOq/t5e3/lQJ/GpXMbwUhoKTkDRVcryeiH18a6zocm+KSqMnVN33UuI7pUVdpe7vKy78N/mxX hLpew1Ux8MmoKqxv7PsginwfJEAc4HSAhEH6p9YZ6QGLYgKsWI7itcXtgQ/yK9Mi3VMQaWOJwGi WAUqf2ouyge8G0g== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 As mentioned in the 'Fixes' commit, the port flag is only supported by the 'signal' flag, and not by the 'subflow' one. Then if both the 'signal' and 'subflow' flags are set, the problem is the same: the feature cannot work with the 'subflow' flag. Technically, if both the 'signal' and 'subflow' flags are set, it will be possible to create the listening socket, but not to establish a subflow using this source port. So better to explicitly deny it, not to create some confusions because the expected behaviour is not possible. Fixes: 09f12c3ab7a5 ("mptcp: allow to use port and non-signal in set_flags") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 37954a0b087d..c921d07e5940 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -1328,8 +1328,8 @@ int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, st= ruct genl_info *info) if (ret < 0) return ret; =20 - if (addr.addr.port && !(addr.flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) { - GENL_SET_ERR_MSG(info, "flags must have signal when using port"); + if (addr.addr.port && !address_use_port(&addr)) { + GENL_SET_ERR_MSG(info, "flags must have signal and not subflow when usin= g port"); return -EINVAL; } =20 --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 EAB2B1AED20; Wed, 31 Jul 2024 11:06:22 +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=1722423983; cv=none; b=slBkKyU5sLP/YN4z70l6TKaR5KR+dMcO1hI4IjefZ4C/gf1e3UqoInTSzkqM1yp28gLyikjKDilYkbnC5eAZJvvYvaqWUWnEprJa+N6ksLg+F00GJ0zfXGFDDi7Re1VEnJ5Y5hP6VZ6vRGCzRClFia9FS7f8B/2EkEInpP1oxlM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423983; c=relaxed/simple; bh=soS1IItRiwvU3ZcudsCwRfsm4gIP9t7k7P3OTrfne/k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ndV5SROreFfCzdH5UaBBf9AovB2CeBqFobqSJ0UK8Lt1+0YcYsl/H3SCO/YdHZ5IrgL42evNtx0ETKsgFpHt8WQya3yNGm0C81c2GHtVA4gGeM3Jqzi+A2JkL8sKVltXqAfnaoFAriG/cCl4mwJXEtkNvqCe9KCEIfz3IEP5+t8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=J9O1HjEJ; 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="J9O1HjEJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C653C4AF09; Wed, 31 Jul 2024 11:06:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423982; bh=soS1IItRiwvU3ZcudsCwRfsm4gIP9t7k7P3OTrfne/k=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=J9O1HjEJYfO+Lvvf5oFcLPjzi1LUc0Vgu92YmIIkaoxiG9tsu5hJXUQJwYzmjHSGe pB3euWZxDGJSWXdr1tUjNb9psKcxILhUdwfCAREaEwzwzvwbyUQ3iYH8Sn+pdmK7d3 ZOLPlW9wJtzwz6JZzWeolCAVolHVeWG49V2zEylj7lxLBsM6aVHiNIR9/b3R/EsKmR dFImaOU7jBio8HTo+c7pWebe5TN8JR9L+984O+wuPUAxKizegQMfSkFt7B/g98/gTc d7KShE0T8nXCsAZKF9XRnNRKEUNI1W7nByp4WiMq7hcuU/vf41sIS23KaqXHuCrV9U xi3QzVsx9xZ0g== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:55 +0200 Subject: [PATCH net 3/7] mptcp: pm: reduce indentation blocks 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-3-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1430; i=matttbe@kernel.org; h=from:subject:message-id; bh=soS1IItRiwvU3ZcudsCwRfsm4gIP9t7k7P3OTrfne/k=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqiNZDjMzEbvK6znw3TvawjCFq4p2dY7gQaM LGj2wO/O4eJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg c5BLEACUSAZDLIvcllvvIGr6OYFIVspsg8xLHr2ouEyUlYAKa/hl1p94ivC12DKB2/qkm/i21QN qJ0a9KWxyRnzuvUCw9Irzfqq9VCSTRhSOviExSSFEXOtMuny/Q7qo5k7734O7jQDORqWux7Tis5 BGOK5botmN1Meen2SLD0A0qLhuEy363JCnt3SevbGUwbysi8l0F3UNhT5iXhBY7N3OytnPWnddZ xV3bQ5+cHYdQP4L6SnBf8hdljdplgs1B4Ci+rTk3WcztK641Q2M8Pm0HAblyYnqpUhOHG1TTcXu DTu1FejDhS7go/LN5u0jBj2WYuK4rwBVCRPNLHyrQ1wVcqXXUqq4YiAl660CzUFi9aiR47kR0d3 QyOxHzjvsvWjMuwGLDRs4ZBRI6F60eaLdhxT5rPhMtBJyzL5hbRdbzvUnbZ197eR5P1QuGlVByF jPevRAIMMN1cK5GTRa4XqE2O1Ay5V9oYuUBpdvISYy02Yao7ovtFBkki9VK8/dz1jiR/7Zg6tUh bdd6qa/M8KDXzfqep+p8YDXRYhp9tRC7U80k7l/SL5c9M7FaoUtYUUxw5nX3E/YJ8ynV4PdmUv3 Oog83rht8PMajvaAOX04qVFl2pN78TZDrAy9pXcd0xE4HF+nFPWQA2X2q3/LYMeayB2eBK6PIb3 Ru1TErPI9h+ffWg== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 That will simplify the following commits. No functional changes intended. Suggested-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_netlink.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index c921d07e5940..780f4cca165c 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -567,16 +567,19 @@ static void mptcp_pm_create_subflow_or_signal_addr(st= ruct mptcp_sock *msk) if (msk->pm.addr_signal & BIT(MPTCP_ADD_ADDR_SIGNAL)) return; =20 - if (local) { - if (mptcp_pm_alloc_anno_list(msk, &local->addr)) { - __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); - msk->pm.add_addr_signaled++; - mptcp_pm_announce_addr(msk, &local->addr, false); - mptcp_pm_nl_addr_send_ack(msk); - } - } + if (!local) + goto subflow; + + if (!mptcp_pm_alloc_anno_list(msk, &local->addr)) + goto subflow; + + __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); + msk->pm.add_addr_signaled++; + mptcp_pm_announce_addr(msk, &local->addr, false); + mptcp_pm_nl_addr_send_ack(msk); } =20 +subflow: /* check if should create a new subflow */ while (msk->pm.local_addr_used < local_addr_max && msk->pm.subflows < subflows_max) { --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 C5EBF1AD9C6; Wed, 31 Jul 2024 11:06:26 +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=1722423986; cv=none; b=moS+5P6DqM7pQgh6mWhNJUpAWY7fjXqyNmtGua04F7EgQt+7pbMJedlvlLgcbr6xadATgsYvngkBej34ToMtGFwNIQtFnXzkrmnax9jMb6y3tiWGvSP5dsQgvc3wVrnnGSTaEk/awiHbOSG51P42N5bQqAtIgSTihuOCA0hCMsI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423986; c=relaxed/simple; bh=ucPLpyidAabxDmr1HFVxowabnIMprlmWSuibzybqmAA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=WP1ogo+ROg9PfA2f060o+ECfz43Tlai3lm7LxW0yjVUmXAw4iVQ0nlxl0Vlz05vFX2m7po6Orv/9CP4q6rcFZd6N4FAYoQLrkqB8bT81cuJJ5JS/1J4UdAujv1dHILcPDFpn+KOl+JCCErJtNl16sAdfCROWEUxh+9hWm1IyvJU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AyXPVGwE; 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="AyXPVGwE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BDF3C116B1; Wed, 31 Jul 2024 11:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423986; bh=ucPLpyidAabxDmr1HFVxowabnIMprlmWSuibzybqmAA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=AyXPVGwEjyG6x+3m+yBeLcssWdtZx2ABrkQYAA0Fm7BFn+BV2znAMxYk35LdEPXyQ MckvKrBJ/qtHrWeR4onoYTm7hW+HCcyAdUmn0QURcJcABGa80cmPL2pZan5Ytev8k1 94tY4dobSSLKeohEjI7jyzgdDPL7icn6gt7sMxf/H4icIGV+LPCL1lAL4zwOxDhHAk RYbx/V9cZ6CDsuFQYsm/V6equZ4Cxt+3NYShC6u5EOPHV4mFtu6tgwocSciVWddmX1 njFIPM06MDqITCH71qy59vPnhM0cQf+R+6THxRK6H3VFLjMq53URlIfeCclPAjrMfM Zk4j1aiuDFV1A== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:56 +0200 Subject: [PATCH net 4/7] mptcp: pm: don't try to create sf if alloc failed 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-4-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=2240; i=matttbe@kernel.org; h=from:subject:message-id; bh=ucPLpyidAabxDmr1HFVxowabnIMprlmWSuibzybqmAA=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqiEzR0/Bx3PYsDk6c9qKT1TOf03HKnCKWrW Cp4i7OpwJSJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg czScEADD382M04ZC2EZjc7pwk7OJrYE+/GJgo4BQnBAINQofX8YQT+krva4UQS6haHZ82kfqABO H7VEUSRBeu71jEGsp2CwopTcR/gRr20BBKyOOAAmY9nA9Ti2uMFFzOt6UFz7PQN6X/8i8jWfMGz M+Y59imDUwedWHR4eZ1a2KazMmcm+Y4Ly6ng+RcVNYD8eI5oZAOpVP88IOJUe1oa0sMB5PCfON6 cJPZVooOMsIz69eFJWzkWN1vEksvNHZ2ERkCga+dJjE8AmezLISVbonVyFOdtrnKb4/pMyK+xlz 6P49u9GLh11YZOiUPeSaARr1dnFeYbZhxqFi4a2IXzCHbYsWF0ObCDGFPjDZPx/Lsrvp/Z56E19 vIerovE3Y1g8YklatplfGvTbwTtZHbriakjhJ9Vl9C25siqJR5tVmKRTCNH5bTWUH6eH4jJ3R+W gaFyz/gZmoxTKqiacZW4GyYIhvY1et9KJLH7J2ihTffK9XQHCok2Yx1BRzeoKlApx91Yxo0QHiu 8BkszTlx2b2OOudk913MIxmaKYHdWvA5FbDsXBZgrBk1Xgicj9vYLJXsp/Wn4nmjilkMJ/LTQBn sPMquwWb5eMWpaHfikM0xs4Y09eHAnwLa/yaFgEQTW1EB7UJLeoNd3LlgrpIo+Aa1DVkddkWTfT 5bTgstTLYFGt35w== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 It sounds better to avoid wasting cycles and / or put extreme memory pressure on the system by trying to create new subflows if it was not possible to add a new item in the announce list. While at it, a warning is now printed if the entry was already in the list as it should not happen with the in-kernel path-manager. With this PM, mptcp_pm_alloc_anno_list() should only fail in case of memory pressure. Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_netlink.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 780f4cca165c..2be7af377cda 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -348,7 +348,7 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk, add_entry =3D mptcp_lookup_anno_list_by_saddr(msk, addr); =20 if (add_entry) { - if (mptcp_pm_is_kernel(msk)) + if (WARN_ON_ONCE(mptcp_pm_is_kernel(msk))) return false; =20 sk_reset_timer(sk, &add_entry->add_timer, @@ -555,8 +555,6 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) =20 /* check first for announce */ if (msk->pm.add_addr_signaled < add_addr_signal_max) { - local =3D select_signal_address(pernet, msk); - /* due to racing events on both ends we can reach here while * previous add address is still running: if we invoke now * mptcp_pm_announce_addr(), that will fail and the @@ -567,11 +565,15 @@ static void mptcp_pm_create_subflow_or_signal_addr(st= ruct mptcp_sock *msk) if (msk->pm.addr_signal & BIT(MPTCP_ADD_ADDR_SIGNAL)) return; =20 + local =3D select_signal_address(pernet, msk); if (!local) goto subflow; =20 + /* If the alloc fails, we are on memory pressure, not worth + * continuing, and trying to create subflows. + */ if (!mptcp_pm_alloc_anno_list(msk, &local->addr)) - goto subflow; + return; =20 __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); msk->pm.add_addr_signaled++; --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 C396C1B0115; Wed, 31 Jul 2024 11:06: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=1722423989; cv=none; b=fFvY5a4z0VX1gippA2Vf5G/+eQX+18jSZ/H0sPKl41gaLBtZeVYn4/7DP4vX/R18pgpKwMG+rU+asP0of1ueUMpabqe5JHF4lXPxtr+9BhHaC5Li5p861t4GNDgKa0PGGY+WZDa29ds50vpCkx3GZd5hj3GesZJ9gmrrev4Ic58= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423989; c=relaxed/simple; bh=vSxE9dZVA5Q6GagAMbC/uiWZrzBxnN5FNeRgFv7dSkY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=XxsbTaLDyOlkKLOt8T3JP2K+ruEF8Fk15tjDOvGeafmh3/yw7VkOLAdycMarvipVat1F6MIBQe5TMuoNk7oT/iE6ocOkFb33AMy240g/V9NDJ1j+7BgFvqyj8XI6GNr2Hq8cKngWZMxRjwS4WJJ28SjoiOcips0zzUI9nkCA+XY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GXQ0o2Hv; 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="GXQ0o2Hv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCFB5C4AF09; Wed, 31 Jul 2024 11:06:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423989; bh=vSxE9dZVA5Q6GagAMbC/uiWZrzBxnN5FNeRgFv7dSkY=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=GXQ0o2HvIsiHxJi7qiok77XRnJPOreCqL1GIk2Pk2DMFcNSZ8iWMCZObZAqTMLePG JvqCzfkY9RsmKgdLzBmSjdv2JHCFNrvgNjfHs4mJtAEfNjwqADWPtvO48+EvX9hHNO Js5OTZ/qB1K5s7dBe+/yaNA1wHz0ULy5pQV4eJh4vk7QU7PtwXFKVaJnRfkCCKmsGk eDfDdXQ0y7GSI2DSql9gqLAAy0iyxA2IOerNHQNhiktRo8/vprCDQFq/fersoZVeaL O2yALOj0tRkWD4WchRJOdZ32AoFW0L3w5GQZcXt53no7Q5YVfnlQGh0cu8ACxC95NZ kGcRw1EcduZYQ== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:57 +0200 Subject: [PATCH net 5/7] mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-5-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=3888; i=matttbe@kernel.org; h=from:subject:message-id; bh=vSxE9dZVA5Q6GagAMbC/uiWZrzBxnN5FNeRgFv7dSkY=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqiJJixt2T17TbHTeIvdJlCr3A5AFQFcvdN3 Pa5IBG39xKJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg c9OQEADX6153k9W+4S1S4qaARvs/quggdZGgZfaQeSPCstSxk0klZoNIIlwUa84dpgBpmIJOJ7n 0MReIIULkJUDYQtNBHeb6g0fz49Q+e4rHA+txEv3BeZZg/R1xbLzoOt/N3eTJk9gcDdU6ZIRmby vjchFAoAdXpxNT939DW3w87wg8qQ5pMZrRwnU2uYxZUDmKa2/kmuGGQzsaVVrQQdPOnD4nU7K5j ZhEa8GXA6m7tmVCRf3AmHlQVlPbsVDkXRM2SZkAf7LKXX5Rzcj3YVpzNmizoSumfA8OmKSqoFE5 d4O9i+0omuUpfx5/ns3UkXH0G1g/eihmQ333G52q0PTx5mW9DhU0tH9LZ6fHzK8ItyvpPBpCHeZ PTmFWTXGhcp2jwXgdWbixZXguSwQpZO9ESRzA43THA6YRSzP98bUi5ZH1GJB9w9oS9YLglYmyzz FmmGKgJrWqi8bJwJy5aXK5sDuM/ikFqqgvqZixM7cqC8dD3MIYEQI2EhbKs0wPD39liZo/NRIPq fMFU53IQTNm3RYXR6al4Ww/OvcQTcd0P0m5qVWWe1voiwioZjlUD8OvlZuvTdj7jvaav0ZbMNm7 mBT/pXl9TxLsTSvjHhTONTfBgE2FPgGVzbiSXrYMSvKsSepA9L1evyc84TDd3JB8hORy69UzEeo CPLDqKGYPLwESkQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Up to the 'Fixes' commit, having an endpoint with both the 'signal' and 'subflow' flags, resulted in the creation of a subflow and an address announcement using the address linked to this endpoint. After this commit, only the address announcement was done, ignoring the 'subflow' flag. That's because the same bitmap is used for the two flags. It is OK to keep this single bitmap, the already selected local endpoint simply have to be re-used, but not via select_local_address() not to look at the just modified bitmap. Note that it is unusual to set the two flags together: creating a new subflow using a new local address will implicitly advertise it to the other peer. So in theory, no need to advertise it explicitly as well. Maybe there are use-cases -- the subflow might not reach the other peer that way, we can ask the other peer to try initiating the new subflow without delay -- or very likely the user is confused, and put both flags "just to be sure at least the right one is set". Still, if it is allowed, the kernel should do what has been asked: using this endpoint to announce the address and to create a new subflow from it. An alternative is to forbid the use of the two flags together, but that's probably too late, there are maybe use-cases, and it was working before. This patch will avoid people complaining subflows are not created using the endpoint they added with the 'subflow' and 'signal' flag. Note that with the current patch, the subflow might not be created in some corner cases, e.g. if the 'subflows' limit was reached when sending the ADD_ADDR, but changed later on. It is probably not worth splitting id_avail_bitmap per target ('signal', 'subflow'), which will add another large field to the msk "just" to track (again) endpoints. Anyway, currently when the limits are changed, the kernel doesn't check if new subflows can be created or removed, because we would need to keep track of the received ADD_ADDR, and more. It sounds OK to assume that the limits should be properly configured before establishing new connections. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_netlink.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 2be7af377cda..4cae2aa7be5c 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -512,8 +512,8 @@ __lookup_addr(struct pm_nl_pernet *pernet, const struct= mptcp_addr_info *info) =20 static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) { + struct mptcp_pm_addr_entry *local, *signal_and_subflow =3D NULL; struct sock *sk =3D (struct sock *)msk; - struct mptcp_pm_addr_entry *local; unsigned int add_addr_signal_max; unsigned int local_addr_max; struct pm_nl_pernet *pernet; @@ -579,6 +579,9 @@ static void mptcp_pm_create_subflow_or_signal_addr(stru= ct mptcp_sock *msk) msk->pm.add_addr_signaled++; mptcp_pm_announce_addr(msk, &local->addr, false); mptcp_pm_nl_addr_send_ack(msk); + + if (local->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) + signal_and_subflow =3D local; } =20 subflow: @@ -589,9 +592,14 @@ static void mptcp_pm_create_subflow_or_signal_addr(str= uct mptcp_sock *msk) bool fullmesh; int i, nr; =20 - local =3D select_local_address(pernet, msk); - if (!local) - break; + if (signal_and_subflow) { + local =3D signal_and_subflow; + signal_and_subflow =3D NULL; + } else { + local =3D select_local_address(pernet, msk); + if (!local) + break; + } =20 fullmesh =3D !!(local->flags & MPTCP_PM_ADDR_FLAG_FULLMESH); =20 --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 6D2A41B1417; Wed, 31 Jul 2024 11:06: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=1722423992; cv=none; b=XeOFRgVAWlTwqX4kaVgbaQddRoSTsOalT9t5J5UqDEaUmsN7IdkUkKVguIY7flEzCHqGF+1MyLsGopV6PrPDQEDPZnVQwGWHbQ1z2u4VGOrJJ0t/9j0/2xJSXC0Tca2Ski52dLS7jnnlqo+b/jSQA760w4N65nU3uAv1liBsHzs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423992; c=relaxed/simple; bh=GF9ZuUb1kC7ALkbKTAdDrcfBWVUj2E5ba2obD4Bwp5I=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=IXkJzxQ6YjSZcEPv3j1GMuSBQn9nOKxVHAevvJB0f3+P6STIC2mC9zuxhbeVKqzXGlLFBwAM2fForf386spArSQn3N7qLRytEVDWL12tNzVLJaPm1WoPoLff72GHP89YgzggZPNKx03+YceEHbHn5poenbQd9pQxDE51HvHUjZA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QkFaRPmT; 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="QkFaRPmT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAF6DC4AF10; Wed, 31 Jul 2024 11:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423992; bh=GF9ZuUb1kC7ALkbKTAdDrcfBWVUj2E5ba2obD4Bwp5I=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=QkFaRPmTofrGDHBzophnwvQs52/o8dLjL0DgIPiWuJczP+laDoqk7OXtKnfe5Mxwi 7b5m8nT8CXvoCyk2kT22SGtQfl5JoJA+GLVaK5ajQrxPnBnUltNGcThT+fB+5c9c3n MrJUsByVIbr6+wu1U74nmLoDtXZZ7FfUOSsmv2ICaKiqEd6+Q7A82KWQYZyPuU7HMQ gzVzikARQTxyDEwwY9sprCy7yEd5XQLa3iJO6IwOIGWirNCmpzesr0ek5JL8aGc/T1 PAk7VcFgLWlAm7z99bwkWGf9jW3788qf+r56OiMoLSeMZ2I/ideLmxI6hFA8SV90Hm NSlGe74BUpWlg== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:58 +0200 Subject: [PATCH net 6/7] selftests: mptcp: join: ability to invert ADD_ADDR check 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-6-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=4336; i=matttbe@kernel.org; h=from:subject:message-id; bh=GF9ZuUb1kC7ALkbKTAdDrcfBWVUj2E5ba2obD4Bwp5I=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqi7s6RNgEUk85ovrvmaAHGLEk++7ljJcA+U gRV0bKTKpSJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg c3IrD/9Mut2dYeV3HYEKGvVtEvg9Dw5pWHvinVqlI5nSmsAR762+NtDsAhS6VYokYzNFfyScwAj w2rDoeUHAUdaLa5BoDwm1Gjq9kpmqLt0ygyGDcPJSf7cKG9XphnPhWg8NtsQQ92X9V6vm7nNCyZ 70jfKY5WCHEzGJmBR8N8fIpGoPnVQUKXm8s6KdpsIZOvpxdkuy5e/v7jWypLiSeAR2saRGq6Dz9 Pcq1lOU4PWQBjq2hKd+3BLc32byM6ZAJrepCoSB9oZbZTseQ4JoK+l3CrfdbFURrfcPCOJttE1L XOk2eTESQ0Z8owjCo1YFHjJotOUv+EnQjKhTculjT3y7L0/WFVuXF/RmpogVg+0WuykuWQehRlU IFTUpayFSdZAnjCuxezntCXgf+qaP4XKPqbSnnN1s4YjHDGi2AA6+mhFFkE28tO+zXn4mRyzyg/ DrFIC4hKBgtn+DcZ2+6hCOUyu9XMReHA2pFWw0ewoXDAxh+AQEsh4Kxr2zTgmfXLeLhK+DJ1KVd iHm2nd7Id/3Mki2aaZwqcxK3OtjKcHC0Kkos+RrnVDCIN1B8zUqWKM/tRh/e80Lx4XqGv/+RZGD 83PncMgDHzGHpNhXHii6jAzonT9+5rCTYpHAox66/8hBR0yOUQ0V9TgNXob88Y/foEWA3RVdfHH ZENFvLZeX+BHu6Q== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 In the following commit, the client will initiate the ADD_ADDR, instead of the server. We need to way to verify the ADD_ADDR have been correctly sent. Note: the default expected counters for when the port number is given are never changed by the caller, no need to accept them as parameter then. 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: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 40 ++++++++++++++++-----= ---- 1 file changed, 26 insertions(+), 14 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 4df48f1f14ab..52a25ac43d10 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1415,18 +1415,28 @@ chk_add_nr() local add_nr=3D$1 local echo_nr=3D$2 local port_nr=3D${3:-0} - local syn_nr=3D${4:-$port_nr} - local syn_ack_nr=3D${5:-$port_nr} - local ack_nr=3D${6:-$port_nr} - local mis_syn_nr=3D${7:-0} - local mis_ack_nr=3D${8:-0} + local ns_invert=3D${4:-""} + local syn_nr=3D$port_nr + local syn_ack_nr=3D$port_nr + local ack_nr=3D$port_nr + local mis_syn_nr=3D0 + local mis_ack_nr=3D0 + local ns_tx=3D$ns1 + local ns_rx=3D$ns2 + local extra_msg=3D"" local count local timeout =20 - timeout=3D$(ip netns exec $ns1 sysctl -n net.mptcp.add_addr_timeout) + if [[ $ns_invert =3D "invert" ]]; then + ns_tx=3D$ns2 + ns_rx=3D$ns1 + extra_msg=3D"invert" + fi + + timeout=3D$(ip netns exec ${ns_tx} sysctl -n net.mptcp.add_addr_timeout) =20 print_check "add" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtAddAddr") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtAddAddr") if [ -z "$count" ]; then print_skip # if the test configured a short timeout tolerate greater then expected @@ -1438,7 +1448,7 @@ chk_add_nr() fi =20 print_check "echo" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtEchoAdd") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtEchoAdd") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$echo_nr" ]; then @@ -1449,7 +1459,7 @@ chk_add_nr() =20 if [ $port_nr -gt 0 ]; then print_check "pt" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtPortAdd") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtPortAdd") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$port_nr" ]; then @@ -1459,7 +1469,7 @@ chk_add_nr() fi =20 print_check "syn" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortSynRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$syn_nr" ]; then @@ -1470,7 +1480,7 @@ chk_add_nr() fi =20 print_check "synack" - count=3D$(mptcp_lib_get_counter ${ns2} "MPTcpExtMPJoinPortSynAckRx") + count=3D$(mptcp_lib_get_counter ${ns_rx} "MPTcpExtMPJoinPortSynAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$syn_ack_nr" ]; then @@ -1481,7 +1491,7 @@ chk_add_nr() fi =20 print_check "ack" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinPortAckRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMPJoinPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$ack_nr" ]; then @@ -1492,7 +1502,7 @@ chk_add_nr() fi =20 print_check "syn" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortSynRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortSynRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$mis_syn_nr" ]; then @@ -1503,7 +1513,7 @@ chk_add_nr() fi =20 print_check "ack" - count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtMismatchPortAckRx") + count=3D$(mptcp_lib_get_counter ${ns_tx} "MPTcpExtMismatchPortAckRx") if [ -z "$count" ]; then print_skip elif [ "$count" !=3D "$mis_ack_nr" ]; then @@ -1513,6 +1523,8 @@ chk_add_nr() print_ok fi fi + + print_info "$extra_msg" } =20 chk_add_tx_nr() --=20 2.45.2 From nobody Wed Oct 30 22:11:13 2024 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 A32DF1B29B5; Wed, 31 Jul 2024 11:06: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=1722423995; cv=none; b=dEjSyXNjYd69nYSqM4DCdsvW6P5cVGqnbzf9rr99V+ByFXezKIYTEu9PcTGN75rsvN0iVprKuvX23BVHB/layRYwIn3kPcnVpl06/aAF7FM79LFAl9vqQOipEZ7yrlK8eMWLQWCcPZ69+AgFIwOYiL4VLULDdyT271tya9ZiifQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722423995; c=relaxed/simple; bh=857ubTu1shYtmLjo2dTYUYNkByMNASD2Yszupp1zLtI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=OWN3qfmThDHMvEP06vlcKaD8o7/x50JQifBA2NHfE91LOcGywm0X3l8Aph908wkSupqc3UvgtiErLKYvKgznPSZsUf3VYreytZI/qqDhfAoVPB/nUWUhVfbir9YXReoga30pu8hyme0wXqFoTdmeVEETQI81930uc/lKar1bNMc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SkTlhcE8; 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="SkTlhcE8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFDE1C4AF10; Wed, 31 Jul 2024 11:06:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722423995; bh=857ubTu1shYtmLjo2dTYUYNkByMNASD2Yszupp1zLtI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=SkTlhcE8fKoAOLEqqIdu/AH9Gkw1KFIPo2QV3RrFyoBrwiVztTtIF6kkF/UlGw+vk K7yYw4C7N7x38HPi2/xliQnLCyNb1f2lXJiCJfIXTGc34LwlGSgn005O/v1EdbEzQ5 Hnoch1dpcfRXE9sbQwcU7rQv5JicFOzhugNCuWqCYV/lMRESnRmh6AnRgsacAj/gfx S82tdH+cYpROSOinIoIIEmESsMwIz7LY4163WhecPaYd8VBDQjgM9JZ+m1106AH48J jUNYmB9stmE/q1svzoVssRrs/L7i99yvVip0t1iRLuafS/G7r2oVmgDQYZeHQNM2+B uy4KcAdw5pazg== From: "Matthieu Baerts (NGI0)" Date: Wed, 31 Jul 2024 13:05:59 +0200 Subject: [PATCH net 7/7] selftests: mptcp: join: test both signal & 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: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-7-c8a9b036493b@kernel.org> References: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> In-Reply-To: <20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-0-c8a9b036493b@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=2447; i=matttbe@kernel.org; h=from:subject:message-id; bh=857ubTu1shYtmLjo2dTYUYNkByMNASD2Yszupp1zLtI=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmqhqixPXnJibSbhI8FfcWQqKkInBror+Nt4EPo SmDkR4qqw+JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZqoaogAKCRD2t4JPQmmg c8D9D/0ZDdboR90bcV5gh2Otr9rWdMbBX45B3y8vyw4qj3jTX7PhgRlw7nsuPHfN7gh1J0oRoGH EqMV2vFKkD9KKfRMspQnVvngda9O3CQHLMT9auMgRDc46bN+m1ZFjudj78glhUgAzlCMhRdCMC0 May+5GnrhsWwDZDOUhuuDnVrxu31//yQNJ7OfNQtKZvbm8CO3hSV6/CT0ZD/xZ2StiWPS1jK41k V4dBqTycQdh06UtUJydzXQSztfigAeblzhElpCtIrslahTrQfWCvMpeU9HodZQOcVsp+aexb+iZ /BTgAOrlKwCibf3labEwnXzuW1EynNrCsYTN+wSWN0EXiXAdTj/eue4IE7NNrilxYn1c5CoLDXF pOvMSuADvo1gb+yBj+AQ1DiG48DjWW86I7fUygOi11HOMz+exc8MISKQvwk7xmacYpeS4jGy5uL YMk+bFuigKSe1Jj4I1/bbVJQqVOIUtMRSw7TP5Jy5qJ/ixJ+0Q1UjTQdpQtDw9sdtjch277xC1b XtK/5UsZCeuIriq/zBWnLqP0anPERG0a/0ltQlGmULkXSPsrCvhRxybqdfBKM9g3Vv5buJOXRHK pcYO2+MJrQgVdu6lkyq2B7fDPeQUKHkwHKJ/GNq/5cCZjx8guzSXeIreDVq2EpdEI1zz0m9gIXI 8Y/wgkHLfXyi41g== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 It should be quite uncommon to set both the subflow and the signal flags: the initiator of the connection is typically the one creating new subflows, not the other peer, then no need to announce additional local addresses, and use it to create subflows. But some people might be confused about the flags, and set both "just to be sure at least the right one is set". To verify the previous fix, and avoid future regressions, this specific case is now validated: the client announces a new address, and initiates a new subflow from the same address. While working on this, another bug has been noticed, where the client reset the new subflow because an ADD_ADDR echo got received as the 3rd ACK: this new test also explicitly checks that no RST have been sent by the client and server. 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: 86e39e04482b ("mptcp: keep track of local endpoint still available f= or each msk") Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 52a25ac43d10..9ea6d698e9d3 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1989,6 +1989,21 @@ signal_address_tests() chk_add_nr 1 1 fi =20 + # uncommon: subflow and signal flags on the same endpoint + # or because the user wrongly picked both, but still expects the client + # to create additional subflows + if reset "subflow and signal together"; then + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 0 2 + pm_nl_add_endpoint $ns2 10.0.3.2 flags signal,subflow + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 + chk_add_nr 1 1 0 invert # only initiated by ns2 + chk_add_nr 0 0 0 # none initiated by ns1 + chk_rst_nr 0 0 invert # no RST sent by the client + chk_rst_nr 0 0 # no RST sent by the server + fi + # accept and use add_addr with additional subflows if reset "multiple subflows and signal"; then pm_nl_set_limits $ns1 0 3 --=20 2.45.2