From nobody Wed Sep 17 16:38:56 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0F212C21FF for ; Tue, 9 Sep 2025 14:33:51 +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=1757428431; cv=none; b=u2PJJyb2N4BuYQOdsvQfaqruK/OboG8XOy+7IOASwJngBBDrFRT1dNpEEsDZiqKxX09SDU/O6I2wiHJbqTw+AtDqqoBWUMYPWrtF9JAO7DMyKcUOd55THUSH75X5k29g8SExsmgd5JJCyf/Lw56fJ3qnCNsF2kgz9tAEhGnjnVE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428431; c=relaxed/simple; bh=n3NvB1/oCYwRv4fdx1OBSDzeShF5o+D/t1XDTGmBupE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=PZ0pmGL6oMkfV2B1HHmM50afRvA1UZ80pIjU3tLRvuY4IpnF44Vr0eOIvW/a2KOeAZPNT0Ro2Pc6sbLb5g9he4FrbFBE8KYy3uCcx5FotUVGyMezn3P9a+JJCoqh8m9nnBBFQjBfm683ZpZYBFaCmO0oMQMtqC1YzixAOx+yH0o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KbcE35Gk; 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="KbcE35Gk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB3DAC4CEFA; Tue, 9 Sep 2025 14:33:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757428431; bh=n3NvB1/oCYwRv4fdx1OBSDzeShF5o+D/t1XDTGmBupE=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=KbcE35Gk49nWHSpAD8Jvo4IxJlJH5Qgup6hGykK0LmXmDVGLK1S3C1wmivivJAOfr ve6O8r3+H6yXXuNBxyTpKmEVrn1w3Vtqh5UMhoO5yIVlK4yisX2WWmN6C8Rkw/BVfJ Pk7z9quLXoWRhBbbOctMzpV82lHYfQJaimAH/P/PaSYlXB7MfxEFCmWyYaCaBeAaFZ 9itJaFhaOn5nCB3tLuaruBNOWJGKAcmhRMC3TBvYWPjGjpa+Wra9foOZYWn9gHp5HI 4cXBgXpqbBZupob2B46YvrqV84iBCdd2PbdaS173DhltR0ZXP3EIZFbRi1PZuNXIeL umaFKfAKLmcGg== From: "Matthieu Baerts (NGI0)" Date: Tue, 09 Sep 2025 16:33:30 +0200 Subject: [PATCH mptcp-net v2 1/5] mptcp: pm: netlink: fix if-idx type 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: <20250909-mptcp-pm-user-c-flag-v2-1-a6f9542481c5@kernel.org> References: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> In-Reply-To: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> To: MPTCP Upstream Cc: "Matthieu Baerts (NGI0)" , Donald Hunter X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1187; i=matttbe@kernel.org; h=from:subject:message-id; bh=n3NvB1/oCYwRv4fdx1OBSDzeShF5o+D/t1XDTGmBupE=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDIOWB3PPDj1Dm+QzPLtHX3nZsiIL77Hafy8hPGmvXN/S tONzu8+HaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABP5MYeR4R/P2b8HI3la7hsI cfr6rnCNi6xsX3x13uSeI02RPtpzDzH80xZhepfo92XXmQWNK76c2+drfHTHlQSZvhuhjj9uG6Y d4gMA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 As pointed out by Donald, when parsing an entry, the wrong type was set for the temp value: this value is signed. There are no real issues here, because the intermediate variable was only wrong for the sign, not for the size, and the final variable had the right sign. But this feels wrong, and is confusing. Fixes: ef0da3b8a2f1 ("mptcp: move address attribute into mptcp_addr_info") Reported-by: Donald Hunter Closes: https://lore.kernel.org/m2plc0ui9z.fsf@gmail.com Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Mat Martineau --- net/mptcp/pm_netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 50aaf259959aeaf36e7ab954c6f7957eaf2bc390..2225b1c5b96666cd4121854c967= a7f3a79824047 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -113,7 +113,7 @@ int mptcp_pm_parse_entry(struct nlattr *attr, struct ge= nl_info *info, return err; =20 if (tb[MPTCP_PM_ADDR_ATTR_IF_IDX]) { - u32 val =3D nla_get_s32(tb[MPTCP_PM_ADDR_ATTR_IF_IDX]); + s32 val =3D nla_get_s32(tb[MPTCP_PM_ADDR_ATTR_IF_IDX]); =20 entry->ifindex =3D val; } --=20 2.51.0 From nobody Wed Sep 17 16:38:56 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD18233EB14 for ; Tue, 9 Sep 2025 14:33:52 +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=1757428432; cv=none; b=Rloq9mlsdO+SUEHZfslHluSIXt3t8P1UtE/R94sk1jD9Yc1SuxS5gcPfd3TPdCqs0IGp6s/3HpPuUj241CuOoy/Bz6s9XFztQJCx0cvb2lvd7V4whNZ84xSYp8zkV1z83YwpxyLedLGSGXSWRrjk1xobiQZfjEqZhjmgiJA6Td0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428432; c=relaxed/simple; bh=5E12JAI4AyzRgMto71JfMTjnNF4ahYzAAEclg/PXuCI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=U0c0IlNpzjZ78ZiccDtkjVIkvDqr+s5G0LedgFGB6mPL8a0AdRBZS2Skt0pTnaKgCQoj6jY8gN361ym1C57o3ywUZ+ZKjjJACXcUfzeeL+1Shb64qqiNjXfS7lnkLQ+l+FfPZ+977Vz7ladoR0tm57D+HBnoi9+L5H7CEUPhWYY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fMDTtiul; 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="fMDTtiul" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF2E4C4CEF7; Tue, 9 Sep 2025 14:33:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757428432; bh=5E12JAI4AyzRgMto71JfMTjnNF4ahYzAAEclg/PXuCI=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=fMDTtiulUU5h+gI9H0Du4jE4o8wXnasUWEspY/eF1+z5BDtPATm3ou87hcM4TOPvg fqnzSRenBXuE2Tzgqi8m73wPq0CpinEGa1Vdvdtru3RH3zQsnEAfqpTxo/L8CTlUnv l3X6fs7YZYniI226GQQeij70WmSYE8wK8U/U44g20tqqiWz+OQ55pLZ78P/CIsL/6Y 9hxOi4eeyvnkuOH91SoFPCD6LYHivM42H82w7XmheHWo46yprthtEE6dwGHbTY6p0L CfoMzjZ48l4brvhBpA5sdSA4Kg2OVrYav7MGZrPuxQmeh3loZZu9qknMcWzySeMkng ovEDhOvdbdWoA== From: "Matthieu Baerts (NGI0)" Date: Tue, 09 Sep 2025 16:33:31 +0200 Subject: [PATCH mptcp-net v2 2/5] mptcp: set remote_deny_join_id0 on SYN recv 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: <20250909-mptcp-pm-user-c-flag-v2-2-a6f9542481c5@kernel.org> References: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> In-Reply-To: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> To: MPTCP Upstream Cc: "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1206; i=matttbe@kernel.org; h=from:subject:message-id; bh=5E12JAI4AyzRgMto71JfMTjnNF4ahYzAAEclg/PXuCI=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDIOWJ14ssjnzXPT9rNHcnY7L+C5ul5UIt70/Jsn+hc1T i+TX6x+v6OUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAiVx0Y/jvY3Spuen2VQ6og U7136rcN+qJTpFjMJFLa5qZ8+LTl5EGGX0wPHp/iFGY+ZDuTe1ElS/CKy8uUZ2p85eTcmLaej79 bnhMA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When a SYN containing the 'C' flag (deny join id0) was received, this piece of information was not propagated to the path-manager. Even if this flag is mainly set on the server side, a client can also tell the server it cannot try to establish new subflows to the client's initial IP address and port. The server's PM should then record such info when received, and before sending events about the new connection. Fixes: df377be38725 ("mptcp: add deny_join_id0 in mptcp_options_received") Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Mat Martineau --- net/mptcp/subflow.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index c8a7e4b59db1150610f99d6e599a9d4cf7e137bc..e8325890a32238bd1fd558b9551= 37a2fa32f66c2 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -883,6 +883,10 @@ static struct sock *subflow_syn_recv_sock(const struct= sock *sk, =20 ctx->subflow_id =3D 1; owner =3D mptcp_sk(ctx->conn); + + if (mp_opt.deny_join_id0) + WRITE_ONCE(owner->pm.remote_deny_join_id0, true); + mptcp_pm_new_connection(owner, child, 1); =20 /* with OoO packets we can reach here without ingress --=20 2.51.0 From nobody Wed Sep 17 16:38:56 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 724C833EB14 for ; Tue, 9 Sep 2025 14:33:53 +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=1757428433; cv=none; b=HW8tRD3reN3ZBw8z3CDQ481XZAnxjyneK/o5ZkM0nLCcqv1dyJxtv1rgag+s5C+zbvk52u3AKj0fOH9nm/5rhrWsMuOVWj+xMd/d+k9SyrIVPR6VDw+/u0Pv/2f8YaUPvxCtMBvvhBtoEw09JU7yk+4rDBbrdKz2W31Lsy7LAlE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428433; c=relaxed/simple; bh=KJMs/owg2K/+WxGOQz3WbPqoN0gy13nceIjRxNYwCbQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=pIzQu8ZC0LBbtD20bVgclhec+4WU3/48gqg72kLPZuh3Rm7fnbEIbSuc9o8sie/mpw/KhF63y0Tn/eQ9V/eqR2siNmIVw0p+HJHvp5CGq6wE1WhxNL5pDuvaxyoLbdJwik1/0l329+voJLvIKorStd5E9PqbrqHphjGztjmXUIA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a+Y4BCsb; 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="a+Y4BCsb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA537C4CEF8; Tue, 9 Sep 2025 14:33:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757428433; bh=KJMs/owg2K/+WxGOQz3WbPqoN0gy13nceIjRxNYwCbQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=a+Y4BCsbXCs/5BDlVEHVF4GHkgDEnvggcBvQbfk9E2Ya1bfPsxPfnw9e+im0RFeie S/xlt+Y2LGxiOcgI7YOP9nMYv0MLXCnJSHN5hk+iXkdpHqZSzJcNvqhlUu6Wbm6bFF cA59G3u04sKrJTzfGfu9L9UiKhPhyyND9L5+XHD8O9DjO9JxPbSPjXUHsp4JHck+nq MBTfxUCRrSoLd5mL04ihk8Zip4/q8942yO2AoUomfyAUovICMixDOOWTQBOcokPEPp XdtbPl1aGUZqGuBVPFAcBcdNqcWiLwYk2OrGCGcYW+d9T6ySBQTYXhwI6ydGX7AgCG NhHXODvgBWtRQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 09 Sep 2025 16:33:32 +0200 Subject: [PATCH mptcp-net v2 3/5] mptcp: pm: nl: announce deny-join-id0 flag 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: <20250909-mptcp-pm-user-c-flag-v2-3-a6f9542481c5@kernel.org> References: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> In-Reply-To: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> To: MPTCP Upstream Cc: "Matthieu Baerts (NGI0)" , Marek Majkowski X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=5286; i=matttbe@kernel.org; h=from:subject:message-id; bh=KJMs/owg2K/+WxGOQz3WbPqoN0gy13nceIjRxNYwCbQ=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDIOWJ3ymt2z/lPzLwGDeSI8t3bFyVlLfVwaPK/I0Up65 tq3om6iHaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABOpXsjwP1Jqi13eo51nF61J CPTovvyq3fz37zKfhAdO51RMnsm9i2BkuP84iENyDm/2qWrWyyG/F99Nfv/qQcCtkLNi1rbSiae juQA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 During the connection establishment, a peer can tell the other one that it cannot establish new subflows to the initial IP address and port by setting the 'C' flag [1]. Doing so makes sense when the sender is behind a strict NAT, operating behind a legacy Layer 4 load balancer, or using anycast IP address for example. When this 'C' flag is set, the path-managers must then not try to establish new subflows to the other peer's initial IP address and port. The in-kernel PM has access to this info, but the userspace PM didn't. The RFC8684 [1] is strict about that: (...) therefore the receiver MUST NOT try to open any additional subflows toward this address and port. So it is important to tell the userspace about that as it is responsible for the respect of this flag. When a new connection is created and established, the Netlink events now contain the existing but not currently used 'flags' attribute. When MPTCP_PM_EV_FLAG_DENY_JOIN_ID0 is set, it means no other subflows to the initial IP address and port -- info that are also part of the event -- can be established. Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-20.6 [1] Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establ= ishment") Reported-by: Marek Majkowski Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/532 Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Mat Martineau --- v2: - now seen as a 'fix' (Christoph) - use 'flags' instead of a new dedicated attribute (Mat) --- Documentation/netlink/specs/mptcp_pm.yaml | 4 ++-- include/uapi/linux/mptcp.h | 2 ++ include/uapi/linux/mptcp_pm.h | 4 ++-- net/mptcp/pm_netlink.c | 7 +++++++ 4 files changed, 13 insertions(+), 4 deletions(-) diff --git a/Documentation/netlink/specs/mptcp_pm.yaml b/Documentation/netl= ink/specs/mptcp_pm.yaml index d15335684ec3d6256505f2b3887ce5818eb57462..d1b4829b580ad09baf4afd73b67= abd7b4ef6883a 100644 --- a/Documentation/netlink/specs/mptcp_pm.yaml +++ b/Documentation/netlink/specs/mptcp_pm.yaml @@ -28,13 +28,13 @@ definitions: traffic-patterns it can take a long time until the MPTCP_EVENT_ESTABLISHED is sent. Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, spo= rt, - dport, server-side. + dport, server-side, [flags]. - name: established doc: >- A MPTCP connection is established (can start new subflows). Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, spo= rt, - dport, server-side. + dport, server-side, [flags]. - name: closed doc: >- diff --git a/include/uapi/linux/mptcp.h b/include/uapi/linux/mptcp.h index 67d015df8893cc1390a483bda034191525b8fef0..5fd5b4cf75ca1e0099e0effa351= 507d3ab002f1e 100644 --- a/include/uapi/linux/mptcp.h +++ b/include/uapi/linux/mptcp.h @@ -31,6 +31,8 @@ #define MPTCP_INFO_FLAG_FALLBACK _BITUL(0) #define MPTCP_INFO_FLAG_REMOTE_KEY_RECEIVED _BITUL(1) =20 +#define MPTCP_PM_EV_FLAG_DENY_JOIN_ID0 _BITUL(0) + #define MPTCP_PM_ADDR_FLAG_SIGNAL (1 << 0) #define MPTCP_PM_ADDR_FLAG_SUBFLOW (1 << 1) #define MPTCP_PM_ADDR_FLAG_BACKUP (1 << 2) diff --git a/include/uapi/linux/mptcp_pm.h b/include/uapi/linux/mptcp_pm.h index 6ac84b2f636ca22935c191c645449fb62b673899..7359d34da446b94be148b363079= 120db03ba8549 100644 --- a/include/uapi/linux/mptcp_pm.h +++ b/include/uapi/linux/mptcp_pm.h @@ -16,10 +16,10 @@ * good time to allocate memory and send ADD_ADDR if needed. Depending o= n the * traffic-patterns it can take a long time until the MPTCP_EVENT_ESTABL= ISHED * is sent. Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, - * sport, dport, server-side. + * sport, dport, server-side, [flags]. * @MPTCP_EVENT_ESTABLISHED: A MPTCP connection is established (can start = new * subflows). Attributes: token, family, saddr4 | saddr6, daddr4 | daddr= 6, - * sport, dport, server-side. + * sport, dport, server-side, [flags]. * @MPTCP_EVENT_CLOSED: A MPTCP connection has stopped. Attribute: token. * @MPTCP_EVENT_ANNOUNCED: A new address has been announced by the peer. * Attributes: token, rem_id, family, daddr4 | daddr6 [, dport]. diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 2225b1c5b96666cd4121854c967a7f3a79824047..483ddbb9ec406a3e965376ee5a8= 33ae295896a02 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -408,6 +408,7 @@ static int mptcp_event_created(struct sk_buff *skb, const struct sock *ssk) { int err =3D nla_put_u32(skb, MPTCP_ATTR_TOKEN, READ_ONCE(msk->token)); + u16 flags =3D 0; =20 if (err) return err; @@ -415,6 +416,12 @@ static int mptcp_event_created(struct sk_buff *skb, if (nla_put_u8(skb, MPTCP_ATTR_SERVER_SIDE, READ_ONCE(msk->pm.server_side= ))) return -EMSGSIZE; =20 + if (READ_ONCE(msk->pm.remote_deny_join_id0)) + flags |=3D MPTCP_PM_EV_FLAG_DENY_JOIN_ID0; + + if (flags && nla_put_u16(skb, MPTCP_ATTR_FLAGS, flags)) + return -EMSGSIZE; + return mptcp_event_add_subflow(skb, ssk); } =20 --=20 2.51.0 From nobody Wed Sep 17 16:38:56 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC78834AAE6 for ; Tue, 9 Sep 2025 14:33:54 +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=1757428434; cv=none; b=jGEwdon7PHouZc4pZ38Ydw5/Yq4iD8AdwYUWB8BT//i5oGKMU9hYaNU8EoPBFq/jLkp0XaunByCUph/10mqCXeOd+r/SeBVUlrpUraLQxHeI6ynuvJhIUac2+n0P+uAyM9wmNiQTPHjqtZIoDQGIjQ6wHa9xwlKMyhjvpqRhogg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428434; c=relaxed/simple; bh=WT4n6Liho45omjO3GNmG9PPgJc/I24mqljKnIRJ2Buo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=twe1mfuAQZQYXUN1K00JX9vf10825fULnChP2j1/G+R40D2EB/lH6QYdaAFDQLRMJbLH2OXxorEKPQ0r9t3ksvaB78UoekvQCNjuX0w1CIvKlZpYvcEdzLzO6ldxii43J5RVwhUgqrLqFhYWTeLGYYe4nD33Trt19P3rfLvscvk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cCZOY6/y; 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="cCZOY6/y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE613C4CEF4; Tue, 9 Sep 2025 14:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757428434; bh=WT4n6Liho45omjO3GNmG9PPgJc/I24mqljKnIRJ2Buo=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=cCZOY6/ysxfrUGLOcZ/YLOkZW3eGXpMQCiR7V3/GTWHcWOB5qRzWJVo2hcxbjMshL +DLWxQt0kiluZATsNCYS15OmL6jNOGowxVW1XG+c90SDxYaB7W4/n3X9bqFm2wcla0 DN7ZWjI4OlmBwC7PP6kyjCM1Zk6KBxERV+Fw4R1ncebKL+JeVifhRnMNfNZMaO2ULV ckC4B7+MW22dpXzk533XP+XzbWYSn1rQLC95n8eFL/OoD3rP37VDPVP5ZkXwZlhb67 tQKXTp0vxDAL7U8hfBNyq1Nx/gZsaDKlFzHA6KqZVPNBx9UO5fzD2Ucu/oKtfDMKpC LIMG2VsJi5Pbw== From: "Matthieu Baerts (NGI0)" Date: Tue, 09 Sep 2025 16:33:33 +0200 Subject: [PATCH mptcp-net v2 4/5] selftests: mptcp: userspace pm: validate deny-join-id0 flag 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: <20250909-mptcp-pm-user-c-flag-v2-4-a6f9542481c5@kernel.org> References: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> In-Reply-To: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> To: MPTCP Upstream Cc: "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3765; i=matttbe@kernel.org; h=from:subject:message-id; bh=WT4n6Liho45omjO3GNmG9PPgJc/I24mqljKnIRJ2Buo=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDIOWJ2+ISDsWXnv0SXHS8Esp+O+HgsKP2afJeY5l/07j 1bH7TtaHaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABNZvJOR4Thfk/fBB/u/6/Ie CPPd+yPy2enQ0N2LhYsPpUQf1RLa+ICRYfVNVqX0CqMn6lXTNOWiTvMGVO46o3Pg5VGH7b+vhRV c5QUA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The previous commit adds the MPTCP_PM_EV_FLAG_DENY_JOIN_ID0 flag. Make sure it is correctly announced when it should. 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: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establ= ishment") Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Mat Martineau --- tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 7 +++++++ tools/testing/selftests/net/mptcp/userspace_pm.sh | 14 +++++++++++--- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/pm_nl_ctl.c b/tools/testing/= selftests/net/mptcp/pm_nl_ctl.c index 994a556f46c15163bae6cb517c371801f0cd6e3b..93fea3442216c8fef43731a99c1= d5710f234b150 100644 --- a/tools/testing/selftests/net/mptcp/pm_nl_ctl.c +++ b/tools/testing/selftests/net/mptcp/pm_nl_ctl.c @@ -188,6 +188,13 @@ static int capture_events(int fd, int event_group) fprintf(stderr, ",error:%u", *(__u8 *)RTA_DATA(attrs)); else if (attrs->rta_type =3D=3D MPTCP_ATTR_SERVER_SIDE) fprintf(stderr, ",server_side:%u", *(__u8 *)RTA_DATA(attrs)); + else if (attrs->rta_type =3D=3D MPTCP_ATTR_FLAGS) { + __u16 flags =3D *(__u16 *)RTA_DATA(attrs); + + /* only print when present, easier */ + if (flags & MPTCP_PM_EV_FLAG_DENY_JOIN_ID0) + fprintf(stderr, ",deny_join_id0:1"); + } =20 attrs =3D RTA_NEXT(attrs, msg_len); } diff --git a/tools/testing/selftests/net/mptcp/userspace_pm.sh b/tools/test= ing/selftests/net/mptcp/userspace_pm.sh index 970c329735ff14f87f0048ba0030dc7edaaa86bc..0801d57a9710406a5942af74271= 9f694e3907558 100755 --- a/tools/testing/selftests/net/mptcp/userspace_pm.sh +++ b/tools/testing/selftests/net/mptcp/userspace_pm.sh @@ -201,6 +201,9 @@ make_connection() is_v6=3D"v4" fi =20 + # set this on the server side only: will not affect the rest + ip netns exec "$ns1" sysctl -q net.mptcp.allow_join_initial_addr_port=3D0 + :>"$client_evts" :>"$server_evts" =20 @@ -223,23 +226,28 @@ make_connection() local client_token local client_port local client_serverside + local client_nojoin local server_token local server_serverside + local server_nojoin =20 client_token=3D$(mptcp_lib_evts_get_info token "$client_evts") client_port=3D$(mptcp_lib_evts_get_info sport "$client_evts") client_serverside=3D$(mptcp_lib_evts_get_info server_side "$client_evts") + client_nojoin=3D$(mptcp_lib_evts_get_info deny_join_id0 "$client_evts") server_token=3D$(mptcp_lib_evts_get_info token "$server_evts") server_serverside=3D$(mptcp_lib_evts_get_info server_side "$server_evts") + server_nojoin=3D$(mptcp_lib_evts_get_info deny_join_id0 "$server_evts") =20 print_test "Established IP${is_v6} MPTCP Connection ns2 =3D> ns1" - if [ "$client_token" !=3D "" ] && [ "$server_token" !=3D "" ] && [ "$clie= nt_serverside" =3D 0 ] && - [ "$server_serverside" =3D 1 ] + if [ "${client_token}" !=3D "" ] && [ "${server_token}" !=3D "" ] && + [ "${client_serverside}" =3D 0 ] && [ "${server_serverside}" =3D 1 ] && + [ "${client_nojoin:-0}" =3D 1 ] && [ "${server_nojoin:-0}" =3D 0 ] then test_pass print_title "Connection info: ${client_addr}:${client_port} -> ${connect= _addr}:${app_port}" else - test_fail "Expected tokens (c:${client_token} - s:${server_token}) and s= erver (c:${client_serverside} - s:${server_serverside})" + test_fail "Expected tokens (c:${client_token} - s:${server_token}), serv= er (c:${client_serverside} - s:${server_serverside}), nojoin (c:${client_no= join} - s:${server_nojoin})" mptcp_lib_result_print_all_tap exit ${KSFT_FAIL} fi --=20 2.51.0 From nobody Wed Sep 17 16:38:56 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D7C534AB11 for ; Tue, 9 Sep 2025 14:33:55 +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=1757428435; cv=none; b=DOyN1v7q1tToTYOP4XeDj2tOUSOurQk9FggHZN10Z46FKQUx4FfevKuNcZUgxXGNxI1E0oFsYkIHtLoDjdPMjRo9br41N2IcAZ8+SEnpEBJdkt0Q76RC7tQEVQlO+heeCKo3gAI2Oz3m2/zvfO61D4p+SMOJnWtZyrVcQyQHGIQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428435; c=relaxed/simple; bh=c8mqTrrxsE8sVwlxKmpcMNt3sh+WaPV3LstRM+dcK+E=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=KaqzuLsGlkS+CNJvvylb1OGaglgglmh09UdopozjjgeBXMDir6keq9GCkqNpFfRIdxcrsmiYKqDhcT6gZhYLtwkP5ixqTOPig5qwrVJn3hfzWdEAzABYS/qg9Ia8u+HjAXXpMDbm950arzuU6P8jx170m+HyB9unghNkLZ+xokI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MvQUi0jJ; 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="MvQUi0jJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8829C4CEF8; Tue, 9 Sep 2025 14:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757428435; bh=c8mqTrrxsE8sVwlxKmpcMNt3sh+WaPV3LstRM+dcK+E=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=MvQUi0jJxSqr7j/vK8BqRmZfk8JmLpFWathjwr6Vr7Lktcx5R8cH/U8VwUdqcL7w1 zyJ5bbOtTUrBP5t0gI4OKri+M9+roNFrcBp+8xwaNj5DqWZJRXuNCf1B/+3E+ANQi7 xJnN1XsaQexRAonZQhqtF+moFEXiAhDkQqx2+3WhFQR6OzBYOobGzhD/rBVPnJGO/m 8BEBNczv065fqtkCtQ5cI+d8kY7HxhEi9pMQwJyOmv6KcMhbIDo4QbxFXZBtjsYiZa ODxBLZrFq/LfoNIvSA2Hzo9cbhH85/rWEZ9yKT0Qyt8IWWTShTponu00CG5UOnLKg3 SnI9PAeGRNwQQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 09 Sep 2025 16:33:34 +0200 Subject: [PATCH mptcp-net v2 5/5] mptcp: tfo: record 'deny join id0' info 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: <20250909-mptcp-pm-user-c-flag-v2-5-a6f9542481c5@kernel.org> References: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> In-Reply-To: <20250909-mptcp-pm-user-c-flag-v2-0-a6f9542481c5@kernel.org> To: MPTCP Upstream Cc: "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1425; i=matttbe@kernel.org; h=from:subject:message-id; bh=c8mqTrrxsE8sVwlxKmpcMNt3sh+WaPV3LstRM+dcK+E=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDIOWJ0xmHbM5dD1ZkGVj3NesU7imLE2UeuV89dl5ldu8 j/9fZr3eEcpC4MYF4OsmCKLdFtk/sznVbwlXn4WMHNYmUCGMHBxCsBEOMQYGf7O7c1mrT6w8/y9 Cb/71duTn09pSz8pdI3f6JpxZdzpWeKMDId7CqdsqZ1d6nZsOnPz2q93165jZiiTmrgwrev51XU /o3kB X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When TFO is used, the check to see if the 'C' flag (deny join id0) was set was bypassed. This flag can be set when TFO is used, so the check should also be done when TFO is used. Note that the set_fully_established label is also used when a 4th ACK is received. In this case, deny_join_id0 will not be set. Fixes: dfc8d0603033 ("mptcp: implement delayed seq generation for passive f= astopen") Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Mat Martineau --- net/mptcp/options.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index d47b8a9bc2df2f14645b1b3d3e10fea1b38567b1..cf531f2d815cdfbc772b837def6= e7d558e64d558 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -985,14 +985,14 @@ static bool check_fully_established(struct mptcp_sock= *msk, struct sock *ssk, return false; } =20 - if (mp_opt->deny_join_id0) - WRITE_ONCE(msk->pm.remote_deny_join_id0, true); - if (unlikely(!READ_ONCE(msk->pm.server_side))) /* DO-NOT-MERGE: use WARN i/o pr_warn: only for MPTCP export */ WARN_ONCE(1, "bogus mpc option on established client sk"); =20 set_fully_established: + if (mp_opt->deny_join_id0) + WRITE_ONCE(msk->pm.remote_deny_join_id0, true); + mptcp_data_lock((struct sock *)msk); __mptcp_subflow_fully_established(msk, subflow, mp_opt); mptcp_data_unlock((struct sock *)msk); --=20 2.51.0