From nobody Thu Nov 5 07:28:14 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=1793259511; b=Y1V7C/CedkAg1q/UPwytqMhCeI1Ln+6UKguvRoHS+tohx01toZTa+GgIj2RPk1uXlyyD bHmsC84B01IoAmpe8/iKsD8dQOZF06Ss9AcYvWc8q2P9LKWxX2Ba17tz8xmDS3IJy+lF7 l0FRkmfH4l6pPye6WWKHmx7MXPv6VygrxFSN3zYGRBPbsazK0Rjm4n7FyUEcK1bJn8nPJ sZQDo3UQFCbXf9GxGjVZlmRWutOm8HHnhS/E7+VG27nXOABwGvm5MebYmvRKzErbcTsy9 KgJ9/Z4S8KcOadPeNZ0nynU2ejVS36psRFS7CiBzDnGNBKD5g+zNyIqhvEDioAHbV2w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793259511; 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=f7ZaVmr25n3n7HlhLcdE1xXGHXxA3Y6h4Fnjr5b4J7/J5GgLkp1L6994tAz78XPWZaJw 5hVIX6Lpvf3dQJ+0lW7sDw6us9znkE8CX6OYPbxcH6dyDUPGMBuutT5hocvISqiFcb0p/ WYK3lYbvwqCPskweO34pBZRFHS2PTVpp4z2FdhXENOFAt/WFKJekdhgAHxwSw+H9U32Mp MTEETmoeDXKquW/kX+Hw6cQ0MgqPVnOuDeg8tsHS+h3Iw4ptIxh//hJt/VhKLWN/7adNp UPGINkKY5UNbn0Yy66leeT5BPIA5WbCxmycq+EgELKI7v70sO7Zvpz1v+aUEa9jk85Q== 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=Pm6PFOOj; 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 580F0606A321 for ; Thu, 29 Oct 2026 07:38:31 +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=Pm6PFOOj Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74C9B1F01829; Thu, 29 Oct 2026 07:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793259511; bh=FcyZ/23EO9wCaimpG8uixyj/1tWZ+pqjTJz3x+0Dc/c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Pm6PFOOjDqlS0TAwpbJJFjPA6Xes6LnPeKSkTZxE12ORw9BvjeCaBQgLjfcuiYdNZ rb5EbE3K8PyXpDCDV0maQxnn9tNM+N4DOVmKaIwT01e5UyTI5iwROEd0F3JOndV2TI WtjSTQlBS22Xn3OQLy4WLhkw5mukujwP1qESZx6kHwEKiMd5s7PcJJ9UOFftsilxmt muI63dRacnegvCOPKMihCZ6zgZRWpvXTvqRiUsPQ5ldZsk6qgVzl9af7yZPIoErNpL zed+iSnef5tA5JEN73gUK/IvWyw8vBeF3uEku69dvY6HGc+/CnbQ3DleCcVYrwM47g PfNARMS4AABkQ== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Gang Yan , Geliang Tang Subject: [PATCH mptcp-next v2 1/5] mptcp: update mptcp_check_readable Date: Thu, 29 Oct 2026 15:38:13 +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: 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:14 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=1793259513; b=GE57N2m1arAYDY8k/JITa0x+r4jokG8SfyDaBkrogU3SniQLvOiz1D+sB9ezKpxRLH9s 8aYgJjhC6CTrwPtrMyjC2d5vqI6/mW7cSqTSy2XHK38H3DrEesj+uYYBzl8i4gaAxS1yL E5a24AaeoJZvA24d6JIxxl1spqFibnGN36YFU18nUKW+EbvMf8Pc2OyDrjSoBerX7U2aK JQKMCV0nWzffRsRo9nv6Cp7TVh3DEKj+CFqixtyGg9cxrPNNiXcYcrUC/u7tPJI70NXms rws2QMt2UmC1dtdNLCQ5zBa81/SJKqxzZDX89Vkz9tqiIlRrj3278B/Dr7pOASpflrQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793259513; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=6mjr4Wn4qKAhBaXcTjNn4QG4/380rbEBnUhSohCKRBY=; b=lZVbYhkvGo0NK2UA+SCB/Tyn0yBohgGCM3IGBiFLwJBSbQFJcM4Q8nP7i2kMajG1yuzS XfQYTb0vN3LtO19v00IF5oOvNoejovjWfHdHjxdW8jMAfHFvIg7B7k0yGX/Wjtyofi858 M7iIjiA7ratXz+IIR5jv+17kWGFzsF7U6BqNAiJIE5mzr5HD19VaI4o+wf1MxXuxH9K2P FDH+b1ujVOgHs66RparYVWHmAP3iy0LRecjokeZ0+zstrFfdQ9D5T+JSHekfJvJ4UKQjq W4PYNhaCxVeozh9NOl78zLLi4GvKN2TbTMyHql0E4JhB0mLbpS6LEkIt385NPF4LJJA== 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=g8FQ3jgS; 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 EFD9F606A31F for ; Thu, 29 Oct 2026 07:38: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=g8FQ3jgS Received: by smtp.kernel.org (Postfix) with ESMTPSA id 803311F031E5; Thu, 29 Oct 2026 07:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793259512; bh=6mjr4Wn4qKAhBaXcTjNn4QG4/380rbEBnUhSohCKRBY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=g8FQ3jgSLatdTXcZNjSpHCCH2VWZCVU+aDLAxu4J8C92mVpqv8P8AcTXNWfk/5qNT pXclS98KFDma7ul2zNSOpiZwJSu+NqNcMFGqDbDm9WsDlI01aF1ix/1Gip+cjx4/nr e5Si2lrayuYSMBCSkAJS8XZjQV6IkctWJS2eoKU1QB8qW1CpAqig0t0GX/OZe0FpmW l8iNJ2dorRiWtFmsUK9rG628iPkO3V94Z3ODslyjg8rc4lDz3fF4Df7mZ1coyA8G2L PDLDBOsXF6KO2p2+TR6n+KgRM9ak/t0/I57d3GrBp7qutOWEzmoWmkiQTqSXaWgrtb aixqreUD9FrgA== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang , Zqiang Subject: [PATCH mptcp-next v2 2/5] mptcp: implement peek_len for proto_ops Date: Thu, 29 Oct 2026 15:38:14 +0800 Message-ID: <5a0397c9d6a1bdbb1ddeb7b2c900a8c1184dee59.1793258749.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 readable bytes at the MPTCP level using mptcp_data_avail() (bytes_received - bytes_consumed) to avoid TFO overflow issues. Returns 0 during handshake or when avail >=3D INT_MAX (likely torn read on 32-bit), and subtracts 1 when DATA_FIN is received (msk->rcv_data_fin), mirroring tcp_inq(). READ_ONCE() is used instead of mptcp_data_lock() because mptcp_inq() will be called from TLS contexts with socket lock held - taking the spinlock would deadlock. Wire into mptcp_peek_len() and assign .peek_len in both mptcp_stream_ops and mptcp_v6_stream_ops. Note: mptcp_inq() differs from mptcp_inq_hint() by returning 0 (not 1) when value is 0, and using mptcp_data_avail() with rcv_data_fin check instead of ack_seq - copied_seq with TCP_CLOSE/RCV_SHUTDOWN check, to correctly handle TFO scenarios. Co-developed-by: Zqiang Signed-off-by: Zqiang Signed-off-by: Geliang Tang --- net/mptcp/protocol.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 0caa31525b90..6f34e3459e8a 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -4797,6 +4797,33 @@ 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); + u64 avail; + int answ; + + if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) + return 0; + + avail =3D mptcp_data_avail(msk); + if (avail >=3D INT_MAX) + return 0; + + answ =3D (unsigned int)avail; + + /* Subtract 1, if DATA_FIN was received. Mirror tcp_inq() */ + if (answ && READ_ONCE(msk->rcv_data_fin)) + 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 +4846,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 +4959,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:14 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=1793259514; b=wRzAIoKWLLGfAc309mYTWP/feulob5U9ywqJft/mScrfLXFKYfZ+QPPj4LUyInYmOEpo 6mYU3uXWXNi87OMm4phEk7OVFSrCQgPII/sJ7MiVzhWwsykqICm4ZrHM8j3+QJ4MHa2sD r/gXjFjUqYN/SMgLPAG7+ISIuFdTVMUddCF++l3ds7A9aayb5Bt4Dz0Bd0uX6a/b8S2H+ nitgqPiJJWTmsJFRauP0wXoq1+NnKuT9n5AppvXVAuvnj3btNf2JcIbeJrHkVQJBhG+IF uuqdaVWHshTrz81ewfQwMVpIAAo2tH6pHO1lvP0Vt2zDTxJ63r6dF7dwdDgb9ud5cIg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793259514; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=HvIJNrDFcfi7s7fRmb/2onkqR3mlzc+IgEvmstGmyMQ=; b=a8SpJxADArEs41kS0tnYi2l2l4LitBulAiGT8Xrf9fQkSYbO7Gvjyorzq//kZIG1w9fy 8Yhkg/iEu9pnH5+3Cl2nnLmOvzxZSe8/EzW57ncT7jTH/dRhauyaVEami7eZUf8jP5lhW 5OHLhAu3b487pzTAsa32nAjblAVzgNNN/C/bnhzmuqYnWm/3rnaGJn2lhfiM7rXMdsC74 iJQMBMDVy+wGYie+Gj03OMQ7VfOnCc6eaW8sILCEdgeVyKDaA/8gBZ+YeR/tjhsyffvqA z9DFvH7U/kHzGNhiaayIQg5Fs2+OxEWN1zpUlmkfKUaB+uZ6iGuqUUSjKmUy5DLfQ3g== 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=Vb9dgDTz; 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 A18AD606A31A for ; Thu, 29 Oct 2026 07:38: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=Vb9dgDTz Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2859A1F01828; Thu, 29 Oct 2026 07:38:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793259514; bh=HvIJNrDFcfi7s7fRmb/2onkqR3mlzc+IgEvmstGmyMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Vb9dgDTz5E+VamNWcoTPlR2jYEr7huWsM5XqHvji9606NmwBDrVZ3HIyyw3LWLkZS nwDQILxK+99uvimAhVeCN2obh5yzkIudX3XwcFNtxzDWLaxNIoDdnQSvoYXBXPS5ov b2ysXTVUXMsAYHLiqHNSpHtl1IsbbVByTVY4vsZWoXT+8dp7jGpqtO6CL6GW6BXNN9 zxZzfSaQCzjMrK9xAbhKujNfO4YtiYZi4xx4OrrUYUb5+usPKf10qqSvzIt2KZKlo9 9GtTA+Lcq6ptXGEBKz9wVDfFvb2bbhCscASwUy2Z3tRJQ8uHsjipHBV6pNG8+ooWDY kI3VrxdCR2MWw== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next v2 3/5] mptcp: add sendmsg_locked to proto_ops Date: Thu, 29 Oct 2026 15:38:15 +0800 Message-ID: <481909c1d5f71b2cca9ab692f251a6213c7cebf7.1793258749.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. Add msk_owned_by_me() assertion to enforce the locking requirement. Expose .sendmsg_locked in both mptcp_stream_ops and mptcp_v6_stream_ops. This prepares for upcoming kTLS and sockmap support. Signed-off-by: Geliang Tang --- net/mptcp/protocol.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 6f34e3459e8a..63d83d4b188b 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2038,7 +2038,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; @@ -2046,12 +2046,12 @@ static int mptcp_sendmsg(struct sock *sk, struct ms= ghdr *msg, size_t len) int ret =3D 0; long timeo; =20 + msk_owned_by_me(msk); + /* silently ignore everything else */ 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) || @@ -2167,7 +2167,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: @@ -2180,6 +2179,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) @@ -4847,6 +4857,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 { @@ -4960,6 +4971,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:14 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=1793259516; b=X0WRRFRABoOgx4uGOyd6mWpaLy6H8mj7esUNzID5J26LKsFglwP4getGJtU3Om1wQltJ UZBqJqPHE4Hp5jwo5BCqOY4CD+ZvK1rM2+1smb8frWK57/0DXi87b/lMMgNURIOqV36mV n3deTqXIX5FKZ2s6/WNQ4Izh1r7FTPbwKKLLEugd9FZh1YXSZn8BWFRNhXWoVwjzILWh6 8b7TebG3A9IJQfvkluHyM3SYIrVBhc9HtRygUi6aYrslv5iPG/zxuutEDRXZVQLFggWmh 5263BBatR1yEv/bH0zK8IKrE8Pfl9525nqhEk08cq1CTceoIYeDK+DKxeBzldYk0DwQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793259516; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=48aP8yultl2N1uAKM9qu4QFmyzBybo5hhc2Ox9jrj1Q=; b=SszT/MKDGSiUOU0l+X6bZBgwShtEnVBCUWLFP3OQ4BF/n159TVQMy0b4qhWoI63iyrTj U81aXwwFeQljKoq/Fxv2AwqLTFm0LZbxUPsqbeoApLmh0bcR7qOR9gVpeK5FoLGPeybro Elvl98i0aWSWgIF0Z12Ug8oDzL6acGqU8m2PEd80XfGeAALOqJhbgRmh/zL9pQ1Slkw1J apJhllntnUarkYop0M+/4MVbppWZiY//vOZUQHDmGeb3BLB9DFkv24WbOSyMTNzUZCJ4a um0WoPtTwMkM8r1t3qZ32AklNxPz/zShpICFu9QsJ5+xoidZs67A3BWPAtdHxbuewrw== 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=PooKzCE1; 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 E270D606A31E for ; Thu, 29 Oct 2026 07:38:35 +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=PooKzCE1 Received: by smtp.kernel.org (Postfix) with ESMTPSA id C51931F01825; Thu, 29 Oct 2026 07:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793259515; bh=48aP8yultl2N1uAKM9qu4QFmyzBybo5hhc2Ox9jrj1Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=PooKzCE1bZzc4UihqitudJDOvfJ0qz85dz4EPsQcKsBPQMuS+RKN/yMZxtkD/OLxC /AgzQGC8fMNy+FsY4tj6tD0pSQyNvp1fhh3LeAg3gvaxf9oPU+izNMrPPZH9RvbrtI uKhB2EkQ25YSZpklExhGo2bMjo3YvUYzjRgIZrdIKir6gxS5YtFh4kR/ttL9Lh6H0q OBSVOuRVxSIIOlLdci41qhLlIe4ZFAUlXguy23TwjHnb9i4mMlTjQMZLDyAtVrR+Ta R/OHbCy+ydQYPinl8L3B/EYv4sfXu6JOgQ40IB9v1gbC0OZmOb8EYS/pxp0kcr+wkH khT3I3AoPPHHg== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next v2 4/5] mptcp: track app-limited state in mptcp_sendmsg Date: Thu, 29 Oct 2026 15:38:16 +0800 Message-ID: <2ff471fbc06c1c748865e61116b6f386310a4d00.1793258749.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_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 63d83d4b188b..8289781a80e5 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2038,6 +2038,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); @@ -2068,6 +2086,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:14 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=1793259517; b=V283v7DYpctqA2Vyll03XkVUFM/+S1t8gXKumNCDVdAIv8udyMGToKrFVXeGVbQsSaJU +YIA/HQEAF0v/OTOSMEctybyxGBFz/WxggOQ2X1giEJYMYzn0SXB43kg1xGtV6eE9NY6t JoZJm4RMwZlLWyL1ZXg3TDmP22iebBiF8OO5e2nHJAf1MCo4fxE5Eub6vEiUBFQtG14UG ksICQuNntnLjy72BedHf6EXzxIOGzLCXqlvFbhnzt3HcTMb1lUPAzS1HP4a/jZsi1eC3i YKXMHg1QZ2qwTkTC+YhiE0Ispjq94NouqEXQIr3tKzX6mBYWa8ne+MT07q8e3mvS2rg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793259517; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=OvSV2HMWa/s1IrAeK2YVLhcVAMU9pwUspa1vCLLae3c=; b=eI+YB1DOsW8e1/GcBTjVvxhZigihCv7WxIWHTHff3xi/20qnrwO4eaQ8suWaU/9ayXSx LpcCFw4TimQA9iCP0S7MdBZ0HgDBKnFGoV6yWbj/S/dL+xe6r/ZS46b7B5z6xXHHoJBOR gBzhDh1emVaLnPPBlOFFgnyZdZQNGPRTP9K/iD+vIJO1afvHRxaJwh3AGA/oFjEQay/sO RIa8P24Yr0bdCCWS381JFTXKIeiiIgn6eG4IX9jSKzEU+TMSQHBibWW6VCUQBb28p203o SXK8vYIHmzo6cWR8OGO7spmWKvZKdiUKWOqoptYGiwgg4vqV8UpAt3sxIHEkc1au8yA== 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=aEM5klJE; 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 4B303606A31E for ; Thu, 29 Oct 2026 07:38: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=aEM5klJE Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2108C1F031E6; Thu, 29 Oct 2026 07:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793259516; bh=OvSV2HMWa/s1IrAeK2YVLhcVAMU9pwUspa1vCLLae3c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=aEM5klJEijcrWpPzJgWmzO+j2PuLoiIFsaTvpTXSDRhSGwchIydOFLMf5Pw7CVFDs OQq/5wH7fCS2Q3g1IHPN1eTZvrHsIkDCKAJV/UHoHnFgj/uadJpboFubTgd/0ZGpYK mgRQXWGfkIQjVFRdgu9A0g1puZswYVaUVUiscw99pZmn8aC5YIgQQ5t7yZjR94G9/W Th0X/Fg+9T2moZUa3mp/ykpfrRiSMIsmc5s5xdJm6atwPLpVeNCFNuo9fitZMrAAWb ctScFVB6NAQ3SsBtrvnUvyVavmnZFpon7McPoZiO4MtPd+KyjFPnsP4p762CW6Zc63 x6dL8z6q2hMRg== From: Geliang Tang To: mptcp@lists.linux.dev Cc: Geliang Tang Subject: [PATCH mptcp-next v2 5/5] selftests: mptcp: sockopt: check app_limited Date: Thu, 29 Oct 2026 15:38:17 +0800 Message-ID: <785e65bbb01dbf31ef2832d7a36c159027d6f22c.1793258749.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 After a small data exchange, assert tcpi_delivery_rate_app_limited =3D=3D 1. rate_app_limited starts at 1 (tcp_init_sock) and is cleared only by non-app-limited rate samples. The preceding commit makes mptcp_rate_check_app_limited() set tp->app_limited on subflows when MPTCP has no pending data, marking outgoing skbs as app-limited so rate samples don't clear rate_app_limited. This guards against regressions in subflow app-limited accounting. 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