From nobody Mon May 25 18:09:25 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF17540756D; Mon, 11 May 2026 15:46: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=1778514413; cv=none; b=Nrr7xKdQQFGR3jlSdA0fcUm1Dnmm14NeMWz9tAKofzY2+r4Nr16ahFGNEYGDzqNm+eXQdHbdXiIJtpiZy3UZ1+xcvTkbvMHh5qTK+ygdX4mbs/oAzPvVuCyZsngAgqPbJsiNLCenUS5e7pfpFZdVKQvmXpe6SXc0V+rTLk+Zh9Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778514413; c=relaxed/simple; bh=qQvn5axOR+yyPoQDWmxod2/JnSKoOIIR/aijmbsFW08=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=S4etmu0HSdMRNx7EKrlvmxiAKJ1dRnQdOBuUL5CkT3Gqwa6bbDXhZFNAZKsBvfj6zpNLSK8jXw7BXVCp4ED9JJ0mUBoPNXWyZ9GeFo1PKFdhYtgGMSP3TAxeUW04Haol4nUqeTWqeQHub3k4Wzkd03old2Ypd3l6KbVEEP1uK08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LdylosbD; 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="LdylosbD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E835EC2BCC9; Mon, 11 May 2026 15:46:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778514413; bh=qQvn5axOR+yyPoQDWmxod2/JnSKoOIIR/aijmbsFW08=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=LdylosbDnxzAsazD/O59xgGIElaxPEfRsB5iXyNnOGcH635D4Lw5XEKFXWMWlov3N yP8OuoMi4C+eVLfq7QrYqDBLxtlBMoowJYcudAMWPbpA3kgvY82oV9RGQrWwLYZ6Ob 4KOuzr2/3WJpuqbAkojbkNkdZHtBvy4k8zkagy0aV7514PTOAB2ESp2VrqCUc+PHZR 7C16N38jgQz2MQOdX3ClWnjwqvme2sOg6anw+Mntr8PynuCf2Ll4uYhUhiecdmUF6Y 7SbfUH4uFXD1WriFbMUee7yh8VcdeV4E795XodZDRz4b3wA14TENaugFPjWC4v1CN5 H+xu34rxaa+eA== From: "Matthieu Baerts (NGI0)" Date: Mon, 11 May 2026 17:46:27 +0200 Subject: [PATCH net 1/5] mptcp: do not drop partial packets 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: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-1-5ee57cb2b7eb@kernel.org> References: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> In-Reply-To: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Eric Dumazet , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Shardul Bankar , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3127; i=matttbe@kernel.org; h=from:subject:message-id; bh=doSwMYEfSiK6uGg6E6Qa8BN/Nu92k84XWlJ5BdjtdXs=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIYfz6ZWeE1yfzkspV394R0XNH5dHOKVWF6pkDM7lJrv n5f1Q+LO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACZifJfhn5149invW49Mba9P +PWhdNoT9/Ny9vN07h88pVC2iIWr/DEjw+U/P19pVhzfFHszkv2SzArzw87y57lcH7itNpn0M8J 9PScA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Shardul Bankar When a packet arrives with map_seq < ack_seq < end_seq, the beginning of the packet has already been acknowledged but the end contains new data. Currently the entire packet is dropped as "old data," forcing the sender to retransmit. Instead, skip the already-acked bytes by adjusting the skb offset and enqueue only the new portion. Update bytes_received and ack_seq to reflect the new data consumed. A previous attempt at this fix has been sent by Paolo Abeni [1], but had issues [2]: it also added a zero-window check and changed rcv_wnd_sent initialization, which caused test regressions. This version addresses only the partial packet handling without modifying receive window accounting. Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/c9b426a4e163aa3c4fe8b80c79f1a610f47ae7d8.1763= 075056.git.pabeni@redhat.com [1] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600 [2] Signed-off-by: Shardul Bankar [pabeni@redhat.com: update map] Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- v3: (Paolo) - update map_seq, too (AI tool) v2: (Shardul) - Drop the mptcp_try_coalesce() attempt for partial packets, since non-zero offset always prevents coalescing (Paolo). - https://lore.kernel.org/20260422143931.43281-1-shardul.b@mpiricsoftware= .com v1: (Shardul) - https://lore.kernel.org/20260422120954.8877-1-shardul.b@mpiricsoftware.= com v0: (Paolo) - https://lore.kernel.org/mptcp/c9b426a4e163aa3c4fe8b80c79f1a610f47ae7d8.= 1763075056.git.pabeni@redhat.com --- net/mptcp/protocol.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 4546a8b09884..859df49e16dc 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -397,12 +397,26 @@ static bool __mptcp_move_skb(struct sock *sk, struct = sk_buff *skb) return false; } =20 - /* old data, keep it simple and drop the whole pkt, sender - * will retransmit as needed, if needed. + /* Completely old data? */ + if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); + mptcp_drop(sk, skb); + return false; + } + + /* Partial packet: map_seq < ack_seq < end_seq. + * Skip the already-acked bytes and enqueue the new data. */ - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); - mptcp_drop(sk, skb); - return false; + copy_len =3D MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq; + MPTCP_SKB_CB(skb)->offset +=3D msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq; + MPTCP_SKB_CB(skb)->map_seq +=3D msk->ack_seq - + MPTCP_SKB_CB(skb)->map_seq; + msk->bytes_received +=3D copy_len; + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len); + + skb_set_owner_r(skb, sk); + __skb_queue_tail(&sk->sk_receive_queue, skb); + return true; } =20 static void mptcp_stop_rtx_timer(struct sock *sk) --=20 2.53.0 From nobody Mon May 25 18:09:25 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 473DD407562; Mon, 11 May 2026 15:46: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=1778514416; cv=none; b=PKer7aKC5WAd3rAxUB1rRECXMD9imVeO/hqyYQh3NDdmz5WGLKRvpu9nRUgWotbQSa88zMj9UwleDsYtplsFBHZ+xjqSL9tKTRiQQFObeoweKK7ykb1GYrMCNRGDsqXtNPMfRVdhExMDEv3bXUZrtF8+WonTF/ALIphcijIYZC4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778514416; c=relaxed/simple; bh=ura07Chl7rB5tl98tzEGB6YAbYJ3qRgqBG5KyqdNSjg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ttXGJAAOQB9F/tOp6k9aq6gfuZ+r41f3NxwaN+1ppJVSL1naDJxaSZR9pydHkoCRE9PjGwtBcm636K38XnY73jUDYe+IqO7djFTmbLFooYIw/BaDDKEWz23/LDUjzreVg1rzrfQ1HWuyBTZsZOyvHABzOxdNuYwK9zVvMVa6D7I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DnxGXhIx; 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="DnxGXhIx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 941E6C2BCF6; Mon, 11 May 2026 15:46:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778514415; bh=ura07Chl7rB5tl98tzEGB6YAbYJ3qRgqBG5KyqdNSjg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=DnxGXhIxwCKfH9iIqMJtgBhlCAuMVlhM8u30Ei8SFELorZ1FvXugdLj6QKXaxVJuQ R/hHZB8Ogbiu8CH3tGubL9YmNgyNFAeG9X6C/jHJTzoJqK7NBiO1gpSUdYAT60ZM8C pC+ZTXLJ7YwrYKYpsGIwRvBP/dQVp/eN9a/y8duLo1soE+HAMpyw8vlRtPWHMte3Ot VYTVYq0MkkooXIhVmP7pWktJ03YGgRx4Y1ij8UHYkMlOor8JrUxu2LzdtnqbXbRVNz nTc8gUsOVHa0BLGj67h3wuG5ioxB2WIghXMb26BlbUZs4e49Bt62e/1zSXyxH/uNO6 a1gOk5sWkD4ZA== From: "Matthieu Baerts (NGI0)" Date: Mon, 11 May 2026 17:46:28 +0200 Subject: [PATCH net 2/5] mptcp: pm: fix ADD_ADDR timer infinite retry on option space insufficient 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: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-2-5ee57cb2b7eb@kernel.org> References: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> In-Reply-To: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Eric Dumazet , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Li Xiasong , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4639; i=matttbe@kernel.org; h=from:subject:message-id; bh=VOnSjP0TUm2WsWL/QY3x2OalMuxDxQgQwzRxuzX0ywo=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIYfz4tfaml2dIS8md9zHl5069Lb3u8W30qpjr+4NYql 3I5lVc6HaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABMRqmFkmDbBxe9e0Rp377Cg F5Y+glGBX++xNi5Y8treslPetvudCiPDUx/fbH1luxMCJ4ITFh9ULjss2zPZw8xVgHvjpcfZi1a yAgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Li Xiasong When TCP option space is insufficient (e.g., when sending ADD_ADDR with an IPv6 address and port while tcp_timestamps is enabled), the original code jumped to out_unlock without clearing the addr_signal flag. This caused mptcp_pm_add_timer to keep rescheduling indefinitely, not sending ADD_ADDR, preventing subsequent addresses in the endpoint list from being announced. Handle this case by clearing the ADD_ADDR signal and skipping the matching ADD_ADDR retransmission entry. The skip path cancels the matching timer (with id check) and advances PM state progression, preserving forward progress to subsequent PM work. This cancellation is inherently best-effort. A concurrent add_timer callback may already be running and may acquire pm.lock before the cancel path updates entry state. In that case, one final ADD_ADDR transmit attempt can still be executed. Once the cancel path sets entry->retrans_times to ADD_ADDR_RETRANS_MAX, the callback-side retrans_times check suppresses further ADD_ADDR retransmissions. Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++--------= -- 1 file changed, 46 insertions(+), 10 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 3c152bf66cd5..3e770c7407e1 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -364,7 +364,13 @@ static void mptcp_pm_add_timer(struct timer_list *time= r) =20 spin_lock_bh(&msk->pm.lock); =20 - if (!mptcp_pm_should_add_signal_addr(msk)) { + /* The cancel path (mptcp_pm_del_add_timer()) can race with this + * callback. Once cancel updates retrans_times to MAX, suppress further + * retransmissions here. If this callback acquires pm.lock first, one + * final transmit attempt is still possible. + */ + if (entry->retrans_times < ADD_ADDR_RETRANS_MAX && + !mptcp_pm_should_add_signal_addr(msk)) { pr_debug("retransmit ADD_ADDR id=3D%d\n", entry->addr.id); mptcp_pm_announce_addr(msk, &entry->addr, false); mptcp_pm_add_addr_send_ack(msk); @@ -414,8 +420,12 @@ mptcp_pm_del_add_timer(struct mptcp_sock *msk, /* Note: entry might have been removed by another thread. * We hold rcu_read_lock() to ensure it is not freed under us. */ - if (stop_timer) - sk_stop_timer_sync(sk, &entry->add_timer); + if (stop_timer) { + if (check_id) + sk_stop_timer(sk, &entry->add_timer); + else + sk_stop_timer_sync(sk, &entry->add_timer); + } =20 rcu_read_unlock(); return entry; @@ -882,6 +892,7 @@ bool mptcp_pm_add_addr_signal(struct mptcp_sock *msk, c= onst struct sk_buff *skb, struct mptcp_addr_info *addr, bool *echo, bool *drop_other_suboptions) { + bool skip_add_addr =3D false; int ret =3D false; u8 add_addr; u8 family; @@ -903,24 +914,49 @@ bool mptcp_pm_add_addr_signal(struct mptcp_sock *msk,= const struct sk_buff *skb, } =20 *echo =3D mptcp_pm_should_add_signal_echo(msk); - port =3D !!(*echo ? msk->pm.remote.port : msk->pm.local.port); - - family =3D *echo ? msk->pm.remote.family : msk->pm.local.family; - if (remaining < mptcp_add_addr_len(family, *echo, port)) - goto out_unlock; - if (*echo) { *addr =3D msk->pm.remote; add_addr =3D msk->pm.addr_signal & ~BIT(MPTCP_ADD_ADDR_ECHO); + port =3D !!msk->pm.remote.port; + family =3D msk->pm.remote.family; } else { *addr =3D msk->pm.local; add_addr =3D msk->pm.addr_signal & ~BIT(MPTCP_ADD_ADDR_SIGNAL); + port =3D !!msk->pm.local.port; + family =3D msk->pm.local.family; } - WRITE_ONCE(msk->pm.addr_signal, add_addr); + + if (remaining < mptcp_add_addr_len(family, *echo, port)) { + struct net *net =3D sock_net((struct sock *)msk); + + if (!*drop_other_suboptions) + goto out_unlock; + + if (*echo) { + MPTCP_INC_STATS(net, MPTCP_MIB_ECHOADDTXDROP); + } else { + skip_add_addr =3D true; + MPTCP_INC_STATS(net, MPTCP_MIB_ADDADDRTXDROP); + } + goto drop_signal_mark; + } + ret =3D true; =20 +drop_signal_mark: + WRITE_ONCE(msk->pm.addr_signal, add_addr); + out_unlock: spin_unlock_bh(&msk->pm.lock); + + /* On pure-ACK option-space exhaustion, stop retrying this ADD_ADDR: + * clear the signal bit, cancel the matching retransmission timer, and + * let the PM state machine progress. + */ + if (skip_add_addr) { + mptcp_pm_del_add_timer(msk, addr, true); + mptcp_pm_subflow_established(msk); + } return ret; } =20 --=20 2.53.0 From nobody Mon May 25 18:09:25 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A1E440B6F7; Mon, 11 May 2026 15:46:58 +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=1778514419; cv=none; b=Ec1CQneYGS6xC/By+0yWyfH1keKycV2WkwvoNwKzUnaQ2+T2RoiXUjoWu20WvS/5PnjqD05QlqI8nOCm9NUIstSSRpKhsnk89758NhlzhZRBkF88Qu57So2q+BGpjpn4hb8CjZZhjTpO4cia7xjBSLkM2IZ0MDCXpucwQgP7VrI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778514419; c=relaxed/simple; bh=HAqn1a+1m/18t3HW1mWpO6nHBtvV4r5btqoAhjlEJO4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=riuuAVFcZEthe2vRDHcoGz03CSV/5W3+UmhO6gwBdy4o9R73uBK18ddcrQQ3tB9nThrwz9WoLWsNf3IkehqLCZCD5Usr3GlgaeddqhRqYF+yuhcwhD9/LakJ96Ew6sjAhhEIFTKfKNx9Q3xhAHpJx/1ykQlMnP/xTOcThnb7lR4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cebHIjI1; 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="cebHIjI1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E93DC2BCB0; Mon, 11 May 2026 15:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778514418; bh=HAqn1a+1m/18t3HW1mWpO6nHBtvV4r5btqoAhjlEJO4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=cebHIjI1t4M/EePTm+I+Z7Dddz+1w5O5adBufhmTu1EuL2twaemVcQejgv7d0k60l ntbDVawsKFkvbNUd3Xu2MhfsBGTOOhfBGwjUpLrfHr1KWWAocJ/P+16TWK1fBLlK/G D8n8H183GtPC/ZZTpR82SXxqFf7mrWOzf0NGymUp25y+xm6WwONu6ijCdJ8D61LM23 3F9pe9k7HQuTWbqdCU5ceSiJq7bioPJ7paNL7/keomMjXAmzeki6JLuQ3npurl8+PO b5/dNZj894Da5gmU2nqAymNy9GJQPdMMAGq3e3oA7L0b9im+xjiJHyBIBSwzA0lZn0 odk7nlrWKl8RQ== From: "Matthieu Baerts (NGI0)" Date: Mon, 11 May 2026 17:46:29 +0200 Subject: [PATCH net 3/5] selftests: mptcp: join: cover ADD_ADDR tx drop and list progress 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: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-3-5ee57cb2b7eb@kernel.org> References: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> In-Reply-To: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Eric Dumazet , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Li Xiasong , Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2117; i=matttbe@kernel.org; h=from:subject:message-id; bh=/orNxmenZ9vHQomKpdCaVKJWq+BaFJUdd4uWduQYZew=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIYfz5lm/XdbW0ZL9fRlqsxqfwSib/av78vMdjQXFa64 dqSj8F3O0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACaS9J7hf+bRsBKNzQIT1q69 17jdoTaUzfnarW26a36Yz25MrN/65QTDP7X088uv/pmYqs200XKz4CNOrX8TI6arnE58wraMfU3 kFz4A X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Li Xiasong Extend add_addr_ports_tests with IPv6 signaling cases that exercise ADD_ADDR tx-space shortage when tcp_timestamps are enabled. Add one case to verify PM still progresses to later signal endpoints after the first one is dropped. This covers both failure accounting and the non-blocking behavior of the announce list after a tx-space drop on pure ACK. Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Breno Leitao --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 31 +++++++++++++++++++++= ++++ 1 file changed, 31 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index beec41f6662a..5acd12021e6e 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1828,6 +1828,22 @@ chk_add_tx_nr() fi } =20 +chk_add_drop_tx_nr() +{ + local drop_tx_nr=3D$1 + local count + + print_check "add addr tx drop" + count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtAddAddrTxDrop") + if [ -z "$count" ]; then + print_skip + elif [ "$count" !=3D "$drop_tx_nr" ]; then + fail_test "got $count ADD_ADDR drop[s] TX, expected $drop_tx_nr" + else + print_ok + fi +} + chk_rm_nr() { local rm_addr_nr=3D$1 @@ -3278,6 +3294,21 @@ add_addr_ports_tests() =20 chk_mpc_endp_attempt ${retl} 1 fi + + # first signal address drops, second one still progresses + if reset "signal addr list progresses after tx drop"; then + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 1 0 + ip netns exec $ns1 sysctl -q net.ipv4.tcp_timestamps=3D1 + ip netns exec $ns2 sysctl -q net.ipv4.tcp_timestamps=3D1 + + pm_nl_add_endpoint $ns1 dead:beef:2::1 flags signal port 10100 + pm_nl_add_endpoint $ns1 dead:beef:3::1 flags signal + run_tests $ns1 $ns2 dead:beef:1::1 + chk_add_drop_tx_nr 1 + chk_add_tx_nr 1 1 + chk_add_nr 1 1 0 + fi } =20 bind_tests() --=20 2.53.0 From nobody Mon May 25 18:09:25 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 736AF40DFBD; Mon, 11 May 2026 15:47:01 +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=1778514421; cv=none; b=NgS3mitwjpvmkoWcdsRDYwJhHvsqHECAZEaKkPPZzpzvbLh1YvVS3oCoW708+EXonpOui23OmtLAFs3b2mV8QeDO3HxP0HcLJ9QHhk1/yOmkjQsTdxoW8+YDlRq3keXYKOHza9GRbtxlDSuYFiGnEMbZJgA/kiAT7uir35e1VQc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778514421; c=relaxed/simple; bh=875ceNXWDGdvQ7I0OyeVxJ2mbgg70m3Ihld1Lkt9Y1g=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=l43w40n3b5qq8svcZTjv/o1yn1lrnZobDoQ9EoSpfbx7GVl5S8XR9moPoEyMKbr9eWFtKrveXg//pxzA58z7vG2hU+QyfGlKFk93iErgmGnC4PFqyMZVR4kuQ4c3z/JDJhyJM/hpU0AoaUJiZV/dZWsVp8qXP3Vb8L9uIHRq/Uk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AxU92nbn; 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="AxU92nbn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D972C2BCC9; Mon, 11 May 2026 15:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778514421; bh=875ceNXWDGdvQ7I0OyeVxJ2mbgg70m3Ihld1Lkt9Y1g=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=AxU92nbnUi5RpyTlHE1q46LvAPGVPlkzn3B1sL8GGpYZD1UjHjeukqYS0yUbuF1VZ /vbDOCLiLx077JAwCsqEwaYXQsVZS93Pt7nb+eJULhs9ZFiUypfQH4QVycYClz9127 8z6oQufxKdlj1kZl4x+EVbN6+qy3AKbWvYe7fKAjTAvE3EBBBGpFXtYyF7aSPFrB+P ul1NlZPQ1UrdbwcmeFEIbNuvH2RwXfpoPFmkVN8tJ5TgdsbwIrDfkkqj9QoaKh6JWA qZpC95O8aE3VTIF53P1FF5TP4LcK46QUCoTZuF5Hk0hCC3+o9G1NG10Byi5CIPgm0u fhl5Fnj/3Gu5w== From: "Matthieu Baerts (NGI0)" Date: Mon, 11 May 2026 17:46:30 +0200 Subject: [PATCH net 4/5] mptcp: reset rcv wnd on disconnect 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: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-4-5ee57cb2b7eb@kernel.org> References: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> In-Reply-To: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Eric Dumazet , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1366; i=matttbe@kernel.org; h=from:subject:message-id; bh=mAbY17mEam5+3zBGBgEjswNy0Y5ydPBnaOl3wDshqq4=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIYfz4rkL1bH6pvPvPktI2erEuilxq2T3yf8N7a8Y7m1 G1T7JxDO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACbyaRojw81pepu8+HmD9zay zt+14eDlZerBFav1mO7f6jsk9aHW0p/hf+XGSsEEVvUjTM8Xaq59Y1ZlzHbhf7dZxKc3vOt2vdD czAEA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni If the MPTCP socket fallback to TCP before the MP handshake completion, the IASN remain 0, and the rcv_wnd_sent field is not explicitly initialized, just incremented over time with the data transfer. At disconnect time such value is not cleared. If the next connection falls back to TCP before the MP handshake completion, the data transfer will keep incrementing the receive window end sequence starting from the last value used in the previous connection: the announced window will be unrelated from the actual receiver buffer size and likely too big. Address the issue zeroing the field at disconnect time. Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 859df49e16dc..a72a6ad6ee8b 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3487,6 +3487,7 @@ static int mptcp_disconnect(struct sock *sk, int flag= s) =20 /* for fallback's sake */ WRITE_ONCE(msk->ack_seq, 0); + atomic64_set(&msk->rcv_wnd_sent, 0); =20 WRITE_ONCE(sk->sk_shutdown, 0); sk_error_report(sk); --=20 2.53.0 From nobody Mon May 25 18:09:25 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1AC4140FDAE; Mon, 11 May 2026 15:47:03 +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=1778514424; cv=none; b=TZJ5cMDL3Gncz0HKMNt6UnZ/Xt7CaKr4vmB0gWyFgSEe8RNFpInFjnl+mX0XqGHL4T3F7+hAJnPJ/ddEZzf7L6x8e1qPIKQD3iXdeuJcESsDTENUkPGoYQUSnJfdvCeYFodKqvtcx0CBc4aHdY8EqD9rMTAS7ZHdE1D7S4vcyNs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778514424; c=relaxed/simple; bh=Pvc4wGSjhVhIBgmeGHWrbxZecHGbRz8bUAOHQrD+mU8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Jc2Afoqoy8uTb99Dq7D6X1PcTz2jTds/e/HVZbTjJTDMgX7IzOIVKA4widWwnB+WKrCDf+8ugcd2/SMJ9hBGf2EA9OCPTPKUXMQBVkIFCWT65MTl7YH/lPURS7E8Mtcg+vPEvKtJkNyAoR3FYBI0w8011qoxquL5KmnhPHhOaXw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RdVmIYXY; 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="RdVmIYXY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86B96C2BCF5; Mon, 11 May 2026 15:47:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778514423; bh=Pvc4wGSjhVhIBgmeGHWrbxZecHGbRz8bUAOHQrD+mU8=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=RdVmIYXYMb5VQdVjU8Wm2wH40QMtOTXfjdVFTdu38SYBLK227uBpOrrNEVVzHOdj/ 8RKyKW5eo/F6N45VG3B4S6SO822ScIb34L+ooaQgmRjIGmg5OpKV6nww/fbMv92MjZ 28+qyfDQks1oGZkKfch2bja78iaSLrNrmumEUHUxJkpvPyB3lGw/Ym1op2NnV5EUcA 8m4vpzMaTbRq+R6g6sIXfKIP+BDzIg2+yhg+BKeIzPpgWvFzotAat04nN89ZJ1Nx+p s66h0CipwMCEBJSqEgrsfvbs9TaUqn+JaY25v62vesNv5IHvzzSStwG/ZKcmA/vkUt CD4zc895xZwIg== From: "Matthieu Baerts (NGI0)" Date: Mon, 11 May 2026 17:46:31 +0200 Subject: [PATCH net 5/5] mptcp: update window_clamp on subflows when SO_RCVBUF is 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: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-5-5ee57cb2b7eb@kernel.org> References: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> In-Reply-To: <20260511-net-mptcp-misc-fixes-7-1-rc4-v1-0-5ee57cb2b7eb@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: Eric Dumazet , netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Gang Yan , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2246; i=matttbe@kernel.org; h=from:subject:message-id; bh=ismW0iII4QhYJ6sgxMbjuN/Lcx0EQOH75zkJ2hNVKak=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIYfz6vrhZ0eCB0QoWh7/CGShNTw57z+mKRcrXLXBcd7 W08fIK/o5SFQYyLQVZMkUW6LTJ/5vMq3hIvPwuYOaxMIEMYuDgFYCIxDowM0+ZuLDF6FGhxyeDa 68WBoluOczWe+FkkuTVqEWPkpRwHUUaGObdqmLavOr5RI0Bh2icVgbIJSXZuEstmfxd+U3DJQus WHwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Gang Yan Add __mptcp_subflow_set_rcvbuf() helper to write the subflow sk_rcvbuf, but also to call the recently added tcp_set_rcvbuf() helper to update window_clamp. This is needed because the window clap is updated when scaling_ratio changes, in tcp_measure_rcv_mss(). Until scaling_ratio changes, the subflow is stuck with the old window clamp which may be based on a small initial buffer. Use this new helper in both mptcp_sol_socket_sync_intval() (setsockopt path) and sync_socket_options() (new subflow creation path). Fixes: b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/619 Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/sockopt.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c index 1cf608e7357b..1544e3563852 100644 --- a/net/mptcp/sockopt.c +++ b/net/mptcp/sockopt.c @@ -67,6 +67,12 @@ static int mptcp_get_int_option(struct mptcp_sock *msk, = sockptr_t optval, return 0; } =20 +static inline void __mptcp_subflow_set_rcvbuf(struct sock *ssk, int val) +{ + WRITE_ONCE(ssk->sk_rcvbuf, val); + tcp_set_rcvbuf(ssk, val); +} + static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optna= me, int val) { struct mptcp_subflow_context *subflow; @@ -100,7 +106,7 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_s= ock *msk, int optname, in case SO_RCVBUF: case SO_RCVBUFFORCE: ssk->sk_userlocks |=3D SOCK_RCVBUF_LOCK; - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf); + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf); break; case SO_MARK: if (READ_ONCE(ssk->sk_mark) !=3D sk->sk_mark) { @@ -1560,7 +1566,7 @@ static void sync_socket_options(struct mptcp_sock *ms= k, struct sock *ssk) mptcp_subflow_ctx(ssk)->cached_sndbuf =3D sk->sk_sndbuf; } if (sk->sk_userlocks & SOCK_RCVBUF_LOCK) - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf); + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf); } =20 if (sock_flag(sk, SOCK_LINGER)) { --=20 2.53.0