From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000191; b=FSBT1StuqLjO0J6HN0D2WBedKR7RoW2RZbO1qsya6kHO4ktDMbm/hfA1d+DVlk8eMeQF k2l9jFoHKX9CJX/X5pflBB/+5HxH2qAZ5qI00025Qfkxsj4PREgsVa2EXFmqEb9gnNdyP uZUKPScBgiFzvZGX/RL4MBxcWpd0DGCWtlqp1RUugPNLu/22kosBb/WxfdVIGvLIMjauH Qejkvu43aI5/QXnl4hXzRGd+XQ4x0sGXToLxwlaZccjehV7LG2uHiXyjv7muKDEKufWqH DGzoEzliE5WLLszsQaB6+waGAeOYkl0knuBL8QbPKdsumdi//d5c9dJRK/kIurnNlsA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000191; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=FcyZ/23EO9wCaimpG8uixyj/1tWZ+pqjTJz3x+0Dc/c=; b=iHtALZBrC/kzDP2S7fAQTS/uaREQVY0ORrolDlwH2M9oTTrSx3zhZ9pDz5K+Gfx1T8uI HTrwX42cKnF9yJCAydc3s5Und+2phvx4uUG5fK+LnO3dDAGufFAQSNf1Rtxn0BLKzefWi 7JV80l3coajnq3w1+gLeCLT+FpFc0CKTXGYaGDhHFgiGzhVnkmsVLd+3yfccEi5183YCc oIdOrkgIYtUw/37Em1jG3feoum3xi1wrJeFnZ4hYMZct/lfNlcaMfs85B8ojVDOYb9Buj IEWcJC4OVxjw6Sp2+VZQh/GgIjwlvBFfM8Sb8FLveAWgjT2PAgSM/o+kKdJ7vqfTBzA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b="gkTuVZ/u"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 076A0606A31A for ; Mon, 26 Oct 2026 07:36:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=gkTuVZ/u Received: by smtp.kernel.org (Postfix) with ESMTPSA id 277211F01825; Mon, 26 Oct 2026 07:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000190; bh=FcyZ/23EO9wCaimpG8uixyj/1tWZ+pqjTJz3x+0Dc/c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gkTuVZ/ubXjZvcZqZ1F8yAsUcfYX0S913/KR7q62R2bO4okpZ9zmKcaJ06fobyd1H +DD3BV2JThUItBFDvJ5zHzQQEG50sY2wt7L7ayz70YbbNj9y5XcpUSemlUEcpbiHW5 WmbVcoPNk9q1XjWvhLROkOqVeiraasM4BcYHZdvNMqxBssaf4D9cq4J1oNUhm/Xx24 DI5D03h0uA6n2Lda2cA6IUARvUJ7cdMhFWknozQ8+6X5PmAlP1IZAflNI4T3UWa2kh 69T2HvScIpTYqBHQUPnesrwbNan0pIIX70r30wmUemKtMuVbueoZh+YTd7hk0bV62L eQ/jjjBRsqy4w== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Gang Yan , Geliang Tang Subject: [PATCH mptcp-next 1/6] mptcp: update mptcp_check_readable Date: Mon, 26 Oct 2026 15:36:17 +0800 Message-ID: <56b390f4512669bab42f013024891aa2af0dca95.1792999988.git.tanggeliang@kylinos.cn> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gang Yan This patch makes mptcp_check_readable() aligned with TCP, and renames it to mptcp_stream_is_readable(). It will be used in the case of KTLS, because 'prot' will be modified, tls_sw_sock_is_readable() is expected to be called from prot->sock_is_readable(). Co-developed-by: Geliang Tang Signed-off-by: Geliang Tang Signed-off-by: Gang Yan --- net/mptcp/protocol.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 02a4f479d9d8..0caa31525b90 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3476,9 +3476,11 @@ void __mptcp_unaccepted_force_close(struct sock *sk) __mptcp_destroy_sock(sk); } =20 -static __poll_t mptcp_check_readable(struct sock *sk) +static bool mptcp_stream_is_readable(struct sock *sk) { - return mptcp_epollin_ready(sk) ? EPOLLIN | EPOLLRDNORM : 0; + if (mptcp_epollin_ready(sk)) + return true; + return sk_is_readable(sk); } =20 static void mptcp_check_listen_stop(struct sock *sk) @@ -4580,7 +4582,8 @@ static __poll_t mptcp_poll(struct file *file, struct = socket *sock, mask |=3D EPOLLIN | EPOLLRDNORM | EPOLLRDHUP; =20 if (state !=3D TCP_SYN_SENT && state !=3D TCP_SYN_RECV) { - mask |=3D mptcp_check_readable(sk); + if (mptcp_stream_is_readable(sk)) + mask |=3D EPOLLIN | EPOLLRDNORM; if (shutdown & SEND_SHUTDOWN) mask |=3D EPOLLOUT | EPOLLWRNORM; else --=20 2.55.0 From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000192; b=SMOAJ+yMsAB1YqUs93g8uhhccpjC1b0gj2VX7eGqAA0i2UlGvZAtXK3KhBbqwkDQ7vOs IDjn8D4BuFoO19IzvVaYh0ziCzLG9NNMJe3LoZNUDyRovXrsXZKbAM9enWdj1rFNRTucp NmKKuoGp3HMUhIASwfl4/7QQHBcbGZ4nxaI8AtM0kPeM9gjyaDQVst/2uf7PNpz11YRi/ jwtx7UN3SJIv+mZnc9gIpyE4dFCg3umSwXpDYRMCi5NqcAqAgDKjmXzRPkXGNWLM/iYNE 3IlWrXaYCewj0vm3fhuePAS5XhkaMC2aU3HLGMG6HW1F5JB/+/5LDGrvSpbexApypzg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000192; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=s3wUI4Rffeqvtew3fCHpivfru7G7wPPHmlZZmjiUDcs=; b=4wYKsZHksUUzv28sfIvkPjgCr+KSO40i0mkPqk3NdXGXoKlYERmwqzD2oe0SgT+np34g mKPuHCUoV8bSTNLl7q7hrnH01McnU2i2iAmQtIFZmK11WV7EhYBch3sy+q9tBN+zboBHr CYywoCoCxGynqy41bHUw2yEzBztngyDfbJqapm4hXa9J0TcBcvW8QgRmezzJ9sszZehpC ABcRT0V199kD5ohldHiK7raPdZruToY4WGmVvmwKMIoCDZQJhYZRiysU1uuA76iAf0Us5 90nhdb6zORsPiHp57+M/EUdaNUfq66otrbBey/HKA2ZCsI60lkM1dXXbQIog30pOkQQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TwkUEP5M; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84D6A606A31A for ; Mon, 26 Oct 2026 07:36:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TwkUEP5M Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CDDD1F01829; Mon, 26 Oct 2026 07:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000192; bh=s3wUI4Rffeqvtew3fCHpivfru7G7wPPHmlZZmjiUDcs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=TwkUEP5MyJb1jbjdW7Wt2Ryve/omxcOMK8wBhS9t0uYwqocNIdJsYPDfQoVUxdeo9 nV2SwYvtwT6jkDWXxnaiIlyTm31FJjuJ7qtiNEsS5XyGrOb3oYx9BX8OH1STwu/ZRe XWHVPXI2XrrQS4wuPm1zfiYnhTCNzxm/n9YsdQdFocQF0yGAFijzrBQ+y6Jb9iiCvj vb93cGoY6CaoSZiZPLUaEmId5GhfrQmRGenrkVctxthN+5XAnjHCfiCo08Sr3KDAs6 IRNKNF0VvdL5rX84yWxjCFdxDOvTq55JtxIHGhnMSfcsN2fO4H6ov03DlPjUPA/B6f 8BgokPPwRq0pQ== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next 2/6] mptcp: prevent dummy DATA_FIN on RST in fallback mode Date: Mon, 26 Oct 2026 15:36:18 +0800 Message-ID: <827c399d23b97b70e59e123d32c7b4b74d3f3987.1792999988.git.tanggeliang@kylinos.cn> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geliang Tang When a fallback subflow receives a TCP RST, subflow_is_done() returns true (because sk_state =3D=3D TCP_CLOSE), causing subflow_sched_work_if_closed() to create a dummy DATA_FIN. This is semantically incorrect - RST is an abortive close, not a clean close with FIN. While mptcp_recvmsg() checks sock_error() before RCV_SHUTDOWN (so the error is correctly returned to userspace), creating a dummy DATA_FIN for RST causes unnecessary state transitions and semantic confusion. Add a check for sk_err in subflow_is_done() to prevent dummy DATA_FIN creation when the subflow was aborted with an error. Signed-off-by: Geliang Tang --- net/mptcp/subflow.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 78e886b20258..a53c83644a40 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1327,6 +1327,9 @@ static void mptcp_subflow_discard_data(struct sock *s= sk, struct sk_buff *skb, =20 static bool subflow_is_done(const struct sock *sk) { + if (READ_ONCE(sk->sk_err)) + return false; + return sk->sk_shutdown & RCV_SHUTDOWN || sk->sk_state =3D=3D TCP_CLOSE; } =20 --=20 2.55.0 From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000195; b=okUrbojggC/DeThl83jNbAphHKv2/23XjsCTxoY/RnkBcqqIS0d/J1oT3n7SSDp+HlJO x/Lk5oQIL7eB07f2YQgu+0gFDXjHaasvT4h+9ZaZyMbjqyygDVilFcfee2bglTQIoydlM JZ70PHy8CqgwFCjhhvLRbb+J32genRC/XD2GSeflngxRkPqxopD/vDGkVzilYVRwVjj9d agO4+LEz+dOuDpETcOFi7iQf05emqrQAvQ8hhYHKwjf3ahedyRYWLlsfRw671+Yl8Z39t I/19Upkd3cx2EoWgrP0K1LccmWDY3PHhogbxv33ludS4EYte6AUz0u/OHKBuRPP4qRg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000195; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=2hIX/Lz/3G303jlREL9Smn0gLuA9pRR+Bqfa+bbZuy0=; b=Br4GyVaTdAKasNq/fUuaGuATP7pxwfEypOOoa9nL7SuP5pWy4iFA+53nGHl5l8Aw3bzK JtocZdVrfS6lQ1i/opp7VgIB/v2wVMg+Vqb2kJ0o/wXarae92hlfxToB3ULMXIitWGonF j7EnP13EmvlZlG0EWbUWyO1VEWYIxtBXT7HTF1XG45UcDBlGv76FozxCa3Y+QMff48adb nwjhY9dn/241BlVc1UWBJr48NE5f6N2Qi2+gvTQsjTJfyKJUQN4NV7DorZZloOgJ+UDM+ q7L3I0H5L3FWhRo0f9uo/sKD8+bDRDtqw6zd3tAjPebUrEfM8mbqbA8n0862lWK9+Dw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=IxXDWMwi; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3668606A31A for ; Mon, 26 Oct 2026 07:36:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=IxXDWMwi Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE4E11F01825; Mon, 26 Oct 2026 07:36:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000194; bh=2hIX/Lz/3G303jlREL9Smn0gLuA9pRR+Bqfa+bbZuy0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=IxXDWMwi1laTVPiQOeo9nqvZLVJlOXLbKbD48dwTdyzgA8oOsih+0N30L4VQdXQZc IrYBz+sE01W7yYdIuNypn9h++ro50xV2Gmxowr6o6yObyBY25YHS/dZD/Tjf5cXSWp 7Ny1sTBpwxlv28ltQWEDsog8gf/GLoV7wiyeyPQ6IvJsfzgOr4Vzxhu8krCa3479ps aGXLzSVnUFXZzmD6aESVlnUm4p9TUYa8ku6iygIXzp7IvAfpmIC81rVCDsyCXPKnKS LLlWBK119EQshkv0J8UoqOxVh08Xdl4lUsIA6kwks9Di8gIQ6Yxrg/QnCVLgD7drZQ 5f5r57L5qeCcA== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang , Zqiang Subject: [PATCH mptcp-next 3/6] mptcp: implement peek_len for proto_ops Date: Mon, 26 Oct 2026 15:36:19 +0800 Message-ID: <22bc848942a31334be17f49a2488c51e2f307eb5.1792999988.git.tanggeliang@kylinos.cn> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geliang Tang Add mptcp_inq() to compute the number of readable bytes at the MPTCP level. It derives the count from ack_seq - copied_seq, returns 0 while the connection is still handshaking (TCP_SYN_SENT/TCP_SYN_RECV), returns 0 when the connection is closed (TCP_CLOSE or RCV_SHUTDOWN), and subtracts 1 once a FIN has been received, mirroring tcp_inq(). READ_ONCE() is used instead of mptcp_data_lock() for the u64 reads of ack_seq and copied_seq because mptcp_inq() will be called from TLS contexts with the socket lock held - taking the spinlock would deadlock. On 32-bit systems a torn read can produce a wrapped subtraction (close to 2^64). When hint_val >=3D INT_MAX, we return 0 instead of INT_MAX to avoid reporting 2GB of readable data when there may be none. This is likely caused by a torn read rather than a legitimate large receive window, as normal receive queues should not exceed INT_MAX bytes. Wire mptcp_inq() into mptcp_peek_len() and assign .peek_len in both mptcp_stream_ops and mptcp_v6_stream_ops. This is preparatory work for an upcoming kTLS-over-MPTCP series. Note: mptcp_inq() intentionally differs from mptcp_inq_hint() when the calculated value is 0. mptcp_inq_hint() returns 1 to signal EOF to ioctl/cmsg users (mirroring tcp_inq_hint()), while mptcp_inq() returns 0 because peek_len should report the actual readable byte count (mirroring tcp_inq()). Co-developed-by: Zqiang Signed-off-by: Zqiang Signed-off-by: Geliang Tang --- net/mptcp/protocol.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 0caa31525b90..71a0a28b0d3c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -30,6 +30,7 @@ #include "mib.h" =20 static unsigned int mptcp_inq_hint(const struct sock *sk); +static int mptcp_inq(struct sock *sk); =20 #define CREATE_TRACE_POINTS #include @@ -4188,7 +4189,7 @@ static int mptcp_ioctl(struct sock *sk, int cmd, int = *karg) lock_sock(sk); if (mptcp_move_skbs(sk)) mptcp_cleanup_rbuf(msk, 0); - *karg =3D mptcp_inq_hint(sk); + *karg =3D mptcp_inq(sk); release_sock(sk); break; case SIOCOUTQ: @@ -4797,6 +4798,39 @@ static ssize_t mptcp_splice_read(struct socket *sock= , loff_t *ppos, return ret; } =20 +static int mptcp_inq(struct sock *sk) +{ + const struct mptcp_sock *msk =3D mptcp_sk(sk); + const struct sk_buff *skb; + u64 hint_val; + int answ; + + if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) + return 0; + + skb =3D skb_peek(&sk->sk_receive_queue); + if (!skb) + return 0; + + hint_val =3D READ_ONCE(msk->ack_seq) - MPTCP_SKB_CB(skb)->map_seq; + if (hint_val >=3D INT_MAX) + return 0; + + answ =3D (unsigned int)hint_val; + + /* Subtract 1, if FIN was received. Mirror tcp_inq() */ + if (answ && + (sk->sk_state =3D=3D TCP_CLOSE || (sk->sk_shutdown & RCV_SHUTDOWN))) + answ--; + + return answ; +} + +static int mptcp_peek_len(struct socket *sock) +{ + return mptcp_inq(sock->sk); +} + static const struct proto_ops mptcp_stream_ops =3D { .family =3D PF_INET, .owner =3D THIS_MODULE, @@ -4819,6 +4853,7 @@ static const struct proto_ops mptcp_stream_ops =3D { .set_rcvlowat =3D mptcp_set_rcvlowat, .read_sock =3D mptcp_read_sock, .splice_read =3D mptcp_splice_read, + .peek_len =3D mptcp_peek_len, }; =20 static struct inet_protosw mptcp_protosw =3D { @@ -4931,6 +4966,7 @@ static const struct proto_ops mptcp_v6_stream_ops =3D= { .set_rcvlowat =3D mptcp_set_rcvlowat, .read_sock =3D mptcp_read_sock, .splice_read =3D mptcp_splice_read, + .peek_len =3D mptcp_peek_len, }; =20 static struct proto mptcp_v6_prot; --=20 2.55.0 From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000197; b=A/UZ9h/jYdrvheL4r3Uap3p0COAnKa4dOncxzulsLqrT5KKyLeUcvuwW1dsxBCrLeR0+ R75UO85pmUuoDR2w++H3gZJVgfKEtH3YO+nM0c9BtexGsuCM3b3ePn+aOZvUjUKeCaGk/ WKub9JAQSec7bkEIapVCUAlDagDxxC7NPSToCn4SdXb/xrs5Nq+EK8SyGAoaR0fh6ytUU Z6WZ9i/Xo5I8RnPb4ucpxRZlJrPgW8V48EzTjCbWO95GUz+jffDKS4D1678hXoTusgivU XE8OEbYlCUZpAOhRon+xS8MDmbbs1zhuJClufZi/yetWIpP/W3GhSH0BiAXdwjQYP/A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000197; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=cCjFYuKXoZDpQfS0zwNSHiokVANG3aQcpI7kE7Wm9sY=; b=OAR2c9jJ8XxlxaLzdHgGJ3Mi6e1tM0R4B3MlTV3etvDEL6a0f7eoDSZj7iSZD73a/g4L vk9F5Vj855ButR9VemNQfWV2xtVQcKCTJw0hmYqaQ2LUK1/nmsw2F/P2MR+4VC8DwUA1R OiEyuFuPuJOpXytsspsHh0DM24tIx2ZtMl1FPvyQ3w6MjE7tQfKcaMSn/kTqwl7I5MvPo Tg+8AjX1MOl/wADBRliBypb4KhN4DBr6Rqex+qR3iXqhLhMOAlEOgYj1NMKioyol2KoSu 20y9MiQ7eJqMvj46a8yjf20rdh2hGivciRhSOI4PUb16JPC4DEeRZ/+Vk40sxsHmX2A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=PhAGuA+v; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69FD5606A31A for ; Mon, 26 Oct 2026 07:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=PhAGuA+v Received: by smtp.kernel.org (Postfix) with ESMTPSA id F20781F01828; Mon, 26 Oct 2026 07:36:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000197; bh=cCjFYuKXoZDpQfS0zwNSHiokVANG3aQcpI7kE7Wm9sY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=PhAGuA+v4IT/6DCoso4sE/0pFWmIlQKNIMoZipR7VtZiFvH918ywfaNyDJn+vjdEB gbHXLU15s35mmJ7uRcEgjfRmMNQ32rpeAkrgxzWMhOGblLWb2qoygoCng/wmNbWO3F D/+e9JP00JYOvI/AGAFGNqI9Xv9ZfEqGjwlJcfM6nfrvCB2vM1FgmZwmOEnYLZwXLd samMjqKB2g48vMMtr5JiGlGvlhlH3mqlV40TO/TLBQag7x772Qv8wseuAU5ks/8jji ciPcPnr1UnbAwtJgfwAku+RFe9nIo/mQsiw4eX4y+JVEDTvD95homfrLpQpynF9L+d 6ttwjC2WXyLWQ== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next 4/6] mptcp: add sendmsg_locked to proto_ops Date: Mon, 26 Oct 2026 15:36:20 +0800 Message-ID: <949a4262ea959da66bcb9fbac72b23f0eecf2879.1792999988.git.tanggeliang@kylinos.cn> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geliang Tang MPTCP currently provides a standard sendmsg() implementation which acquires and releases the socket lock internally. However, certain upper layers need to call the sendmsg method while the socket lock is already held. Split the existing mptcp_sendmsg() into mptcp_sendmsg_locked() which assumes the caller holds the socket lock, and a tiny wrapper mptcp_sendmsg() that acquires the lock and calls the locked version. Expose .sendmsg_locked in both mptcp_stream_ops and mptcp_v6_stream_ops. Signed-off-by: Geliang Tang --- net/mptcp/protocol.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 71a0a28b0d3c..8aad55e0cce7 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2039,7 +2039,7 @@ static void mptcp_rps_record_subflows(const struct mp= tcp_sock *msk) } } =20 -static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) +static int mptcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_= t len) { struct mptcp_sock *msk =3D mptcp_sk(sk); struct page_frag *pfrag; @@ -2051,8 +2051,6 @@ static int mptcp_sendmsg(struct sock *sk, struct msgh= dr *msg, size_t len) msg->msg_flags &=3D MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL | MSG_FASTOPEN | MSG_EOR; =20 - lock_sock(sk); - mptcp_rps_record_subflows(msk); =20 if (unlikely(inet_test_bit(DEFER_CONNECT, sk) || @@ -2168,7 +2166,6 @@ static int mptcp_sendmsg(struct sock *sk, struct msgh= dr *msg, size_t len) } =20 out: - release_sock(sk); return copied; =20 do_error: @@ -2181,6 +2178,17 @@ static int mptcp_sendmsg(struct sock *sk, struct msg= hdr *msg, size_t len) goto out; } =20 +static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) +{ + int ret; + + lock_sock(sk); + ret =3D mptcp_sendmsg_locked(sk, msg, len); + release_sock(sk); + + return ret; +} + static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied); =20 static void mptcp_eat_recv_skb(struct sock *sk, struct sk_buff *skb) @@ -4854,6 +4862,7 @@ static const struct proto_ops mptcp_stream_ops =3D { .read_sock =3D mptcp_read_sock, .splice_read =3D mptcp_splice_read, .peek_len =3D mptcp_peek_len, + .sendmsg_locked =3D mptcp_sendmsg_locked, }; =20 static struct inet_protosw mptcp_protosw =3D { @@ -4967,6 +4976,7 @@ static const struct proto_ops mptcp_v6_stream_ops =3D= { .read_sock =3D mptcp_read_sock, .splice_read =3D mptcp_splice_read, .peek_len =3D mptcp_peek_len, + .sendmsg_locked =3D mptcp_sendmsg_locked, }; =20 static struct proto mptcp_v6_prot; --=20 2.55.0 From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000199; b=kS3rn4CZEF+4/9xlyGYT6r+gMVNnjJO4H58ftRsLVsunQcA2YlAw2UmoNy/qyF6GalBz h5rIgeoTivHEBge9K5vz/meVRc4Q1djGnPSBd769IMJ6HLoMKVAqcMM93iG4NDDvrYpM3 xA1a9OMWcW7Ge/YqutGOKr/lBfKgcSEg8ysBM1p/YtTWYwMYHqdkSlkjZ0pd7Z4yftmQj MRue0qBGzgTTj34U7Uii5L5vDyoU9JXaHem2Ku602GweqWm2SSHE8kCAZ6Oz9NqqKt4pf S7CpJcxsDMM6SqTmb0owharcIGs0v29k1crMgct+1MZUZqTDWySmsbnOAiTx4CnstnQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000199; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=VODG3h47/Vzu4ftrz0xLYwqWjt+8jmX8qe2xsUmQWK8=; b=KUAFh+IbrmZ38aS3X2MamS11aC+SmCJGnwp4oAKzSdTPNWRtGGKGDSD+piqsxcbQ7TiB cwKdLTURk7XMcdgEbAsb/xrdOht5oj0AaNY+rIsJ0QX1XJoXR4y2gAP1+qEZk2d6zMfLJ BKEFFcEiBWhc1IGI+Xx4qwftVWWEx++XhY13Nsqed3a2GX49TjgF6QLQuGPfaN0J2Wqcf URHNz8dNA3qKj4w0/Eq54iOaFcXMMN3P0hLCWWzi8r2q3WEunZB4PA5mI1qN+52Lo91YK fOd+RdIiqufwthQ4y1slEU91IR017AQhrF4817b9cM6ViP0h1vYmttg9ePVvDmuUNhQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TSqXev3W; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F3DF606A31F for ; Mon, 26 Oct 2026 07:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=TSqXev3W Received: by smtp.kernel.org (Postfix) with ESMTPSA id B903B1F031E0; Mon, 26 Oct 2026 07:36:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000199; bh=VODG3h47/Vzu4ftrz0xLYwqWjt+8jmX8qe2xsUmQWK8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=TSqXev3W8knjZo5LM6pdUItqY8k3HKk5rVbTYvmCE2vxa/4eLtcBBYn2zEzojwZhP 2KP7FVcm3Fn/gmj1jCF+7wqxV+R5a7ICFBCMEn6mclNAJUJsLsxPb+loqzKhOiBXc8 rKGLtMhnWmMWbNdEqItvH+q/vOxWE7vLwLucagtZD+b8xQFKJJ6FTpWtCtjeZfButY IjzCbQAxxazFW/NdqsgOFT1QrRAXLDGPA4kdg+Qp1SpyVIf39f1OjjbuIGTCj9AEFJ GEn7wYZn3sT93XsG1sbCI49aEFqTi8jylg2W8sSBP2QT+mPHyqILuXurPjuG4pn7O5 aKKvbUQ9Nv4TQ== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next 5/6] mptcp: track app-limited state in mptcp_sendmsg Date: Mon, 26 Oct 2026 15:36:21 +0800 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geliang Tang Add mptcp_rate_check_app_limited() that walks every subflow of the mptcp_sock and runs tcp_rate_check_app_limited() under each subflow's socket lock. The helper bails out early when MPTCP still has unsent data: - msk->write_seq !=3D msk->snd_nxt: new data not yet pushed - mptcp_send_head(sk) !=3D NULL: re-injected data from rtx queue during failover or stale-subflow recovery In these cases the subflows may look idle only because data has not been pushed down yet, and marking them app-limited would be wrong. Invoke mptcp_rate_check_app_limited() from mptcp_sendmsg_locked() right after the send-side setup, so the delivery-rate app_limited state stays in sync with what the application actually has to send across each subflow. With this in place, subflow rate samples taken while the MPTCP connection is genuinely application-limited are flagged as such, allowing congestion controllers like BBR to ignore them when estimating bandwidth. Signed-off-by: Geliang Tang --- net/mptcp/protocol.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 8aad55e0cce7..568b6b52734b 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2039,6 +2039,24 @@ static void mptcp_rps_record_subflows(const struct m= ptcp_sock *msk) } } =20 +static void mptcp_rate_check_app_limited(struct sock *sk) +{ + struct mptcp_sock *msk =3D mptcp_sk(sk); + struct mptcp_subflow_context *subflow; + + if (msk->write_seq !=3D msk->snd_nxt || mptcp_send_head(sk)) + return; + + mptcp_for_each_subflow(msk, subflow) { + struct sock *ssk =3D mptcp_subflow_tcp_sock(subflow); + bool slow; + + slow =3D lock_sock_fast_nested(ssk); + tcp_rate_check_app_limited(ssk); + unlock_sock_fast(ssk, slow); + } +} + static int mptcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_= t len) { struct mptcp_sock *msk =3D mptcp_sk(sk); @@ -2067,6 +2085,9 @@ static int mptcp_sendmsg_locked(struct sock *sk, stru= ct msghdr *msg, size_t len) =20 timeo =3D sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT); =20 + /* is sending application-limited? */ + mptcp_rate_check_app_limited(sk); + if ((1 << sk->sk_state) & ~(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)) { ret =3D sk_stream_wait_connect(sk, &timeo); if (ret) --=20 2.55.0 From nobody Thu Nov 5 07:28:36 2026 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793000201; b=3xbQedcbx3owxwAcis5HeoLXc32Qyk8kV9A0fAO+r//s8p7MmbOusZFcWvnW91HqIFyc wET5BaJtCrQUwdB+AJVWGz35tL2vPG6B1NeBXphGo5lHbJw35LJQMuhGMYJBLNyfrJd2s BsigPdgU6xCCjeXdAVAoniclpOsRFkGS3Thtl6vblTaOSr4poYjQaxlQpWsCOXoPO9SmZ H9RPT/RBuS4I12oYhoQ5qfc420FXMuKHJZENmoINiqaq+dIa7sp3DK78QKyeVB+o1LCqZ +M+6p2hyjkpP1NH4mc1lX2/mUUxVIJgmccgfL9HneoW+ckrTpkI3oC2A+IUtd8yFpOQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793000201; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=KmQGwESvjyYGFAEUCwtQdVEpNgzKzR5UPK/xoXK65Y4=; b=HBUSHv+Q9Tw+BDa0A8MyXsxp4B12uFscaLysBWIi9w0PyzXubu+avlykVEtGAOGXJF8m iWJciveCFcYf68vJUYgt4U7AarTuv9tJbd9WDflh3/TeejeAqxBaRQzd0WWZ1Bb7GD7dO mNvYk0VmRTFB0Or6k0HWFwNpzEsIC4KDEPqul5QAwkVXQX8RvSnqFrW7p922f7SrGk7b9 ZgOvg6EatcXga2sP/7+1PXJo6OKCv265ou8242L6XUBKaRC8xnOvpnTwNqT5ha7rUsyAm 7/fa00DuVZ+3sCTL2q1oZU02BsKccOrA/w0gY0HiZ/hNz28161Rza4ZiymvSbxgMRsg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=LJCVMbtb; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC5E7606A31B for ; Mon, 26 Oct 2026 07:36:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=LJCVMbtb Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2F061F01828; Mon, 26 Oct 2026 07:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793000200; bh=KmQGwESvjyYGFAEUCwtQdVEpNgzKzR5UPK/xoXK65Y4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=LJCVMbtbZR+PKVphVfl/pM4RZ6k/xmqyWa+BR0jY6cveN3qM0Qpb37rnDJ1Imd5Qn 3g1lEHAlIBi/9MTbBD3xGC7VKfH4Eow4vgbaL0jJT1466A1J/OCneeO1VPz4JcnbZ5 VhsyHpb7eKkFfEIKQAXjB4W2CxjnP+Se0NoSkrGR67Rhjiy0fN0LcETQLu4P3HgriB vYmwlxIEGQ0B0c1BES20gd8zQ4WvDTViN2qZN/E+w1OJDeMdVn6zO3CpxUlWf+oDPg JgkcT88u5NnENMUcC7BoyKMijD73sAVV46k6JIg/o8qGHUBpeUObvlzTrHbSViR3zQ INFXGTQqYL4iQ== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next 6/6] selftests: mptcp: sockopt: check app_limited Date: Mon, 26 Oct 2026 15:36:22 +0800 Message-ID: <8e5aa0a0ec2790efe1e793cf88ab50e11ef6302c.1792999988.git.tanggeliang@kylinos.cn> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geliang Tang connect_one_server() in mptcp_sockopt exchanges only a few packets between the client and server, then closes the socket. After such a small transfer the application has nothing further to send, so the connection is, by definition, application-limited. Extend the TCP_INFO readback at the end of the function to assert s.tcp_info.tcpi_delivery_rate_app_limited =3D=3D 1. The rate_app_limited field is initialized to 1 in tcp_init_sock() and is cleared to 0 only by valid non-app-limited data samples. Without the preceding commit, mptcp_sendmsg() never updates the per-subflow app-limited state. In lossless veth environments, valid samples typically clear the flag during data transfer, so the assertion would fail. With the preceding commit, mptcp_rate_check_app_limited() re-sets rate_app_limited to 1 when the MPTCP connection is application-limited, so the assertion passes. This turns the test into a regression guard for the subflow-side application-limited accounting. Note: This assertion alone does not prove the new code is working, since rate_app_limited starts at 1. However, in practice, valid samples clear it during transfer, so seeing 1 afterward indicates our code re-set it. Signed-off-by: Geliang Tang --- tools/testing/selftests/net/mptcp/mptcp_sockopt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_sockopt.c b/tools/test= ing/selftests/net/mptcp/mptcp_sockopt.c index b8158a1198eb..f7a45b93cbe0 100644 --- a/tools/testing/selftests/net/mptcp/mptcp_sockopt.c +++ b/tools/testing/selftests/net/mptcp/mptcp_sockopt.c @@ -635,6 +635,11 @@ static void connect_one_server(int fd, int pipefd) do_getsockopts(&s, fd, total, total); =20 assert(s.mptcpi_rcv_delta =3D=3D (uint64_t)total); + + /* app-limited accounting requires a recent kernel */ + if (expect_all_features()) + assert(s.tcp_info.tcpi_delivery_rate_app_limited =3D=3D 1); + close(fd); } =20 --=20 2.55.0