From nobody Sat May 11 21:38:34 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1DBB41225; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TO7IGrzz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03943C433D9; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697653443; bh=uMZX/B6ZarsMvm/WGOAr/UwyvhAfU161tjHBCE2TWoM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=TO7IGrzznb0rQDyEGWS+KgZS5bxB/kk/bW0u1rPFpaskzCIZ1vNkX1IU4m3Pwt4nh NaIcelycInJ724A0JCHGRxrWgQJWzWwA7EMMEzeSBwZWNjCAwEKK+jIX+PfktFgiCw E1nyawsIO4Lfec7fwCpA4ndx2FEcSXuM5a6rSIgwhF/r9QMUEgi6CFESw+yBgj0gYB A1THBnPf3JG7KD88uGyKnzO0h9zsMDHpaXiMJo3o8mqgxSz1WVlGBR99NCCkwvB1s3 M2o7dIh604rdREaViAxegxMOSawQ+edmgm8LHAJVUyTysgm+H3oxxYEUxw0Jmava7m s0Q+ANhTDE+1A== From: Mat Martineau Date: Wed, 18 Oct 2023 11:23:52 -0700 Subject: [PATCH net 1/5] selftests: mptcp: join: correctly check for no RST 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: <20231018-send-net-20231018-v1-1-17ecb002e41d@kernel.org> References: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> In-Reply-To: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> To: Matthieu Baerts , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Davide Caratti , Christoph Paasch , Florian Westphal Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, Mat Martineau , stable@vger.kernel.org X-Mailer: b4 0.12.3 From: Matthieu Baerts The commit mentioned below was more tolerant with the number of RST seen during a test because in some uncontrollable situations, multiple RST can be generated. But it was not taking into account the case where no RST are expected: this validation was then no longer reporting issues for the 0 RST case because it is not possible to have less than 0 RST in the counter. This patch fixes the issue by adding a specific condition. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-ca= ses") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index ee1f89a872b3..27953670206e 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1432,7 +1432,9 @@ chk_rst_nr() count=3D$(get_counter ${ns_tx} "MPTcpExtMPRstTx") if [ -z "$count" ]; then print_skip - elif [ $count -lt $rst_tx ]; then + # accept more rst than expected except if we don't expect any + elif { [ $rst_tx -ne 0 ] && [ $count -lt $rst_tx ]; } || + { [ $rst_tx -eq 0 ] && [ $count -ne 0 ]; }; then fail_test "got $count MP_RST[s] TX expected $rst_tx" else print_ok @@ -1442,7 +1444,9 @@ chk_rst_nr() count=3D$(get_counter ${ns_rx} "MPTcpExtMPRstRx") if [ -z "$count" ]; then print_skip - elif [ "$count" -lt "$rst_rx" ]; then + # accept more rst than expected except if we don't expect any + elif { [ $rst_rx -ne 0 ] && [ $count -lt $rst_rx ]; } || + { [ $rst_rx -eq 0 ] && [ $count -ne 0 ]; }; then fail_test "got $count MP_RST[s] RX expected $rst_rx" else print_ok --=20 2.41.0 From nobody Sat May 11 21:38:34 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ED75F4123A; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hGXSAj+h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46FE9C4339A; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697653443; bh=wgF2DRUgasKE34DdDKzqsvEchHtBI9vBd4zl65+aas4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=hGXSAj+hDhRJ2xW5fbYQtHKdrdPH2NJpj+IKM280SZr8gaG3SMx1BW5XnELvZhu3r RRrGvZAU/+j+FnCNqYVgAJJXGm5nUv/Dc2GIaRjSMKtOcTgARHYcXL8IIUMfzy8TS8 utjSM40Nm4A2KBnno6frI6VGGgH+4nskbyUUEDEq/DsQ1WhhGKIuuG+eR6UH43ZI0G fwyMLPiDIigXkzMGm2n4nPcL86KxGwWdE4QPWE79yEjNwnu5wJKj6+L7QyaqX2lyoQ OjtlmADwbXa4ZXK7StjClbds33++twH1u9COGidRGDhn2+Q1iQHtUuP0O50z4FfvkA rzURdCZgx/8UQ== From: Mat Martineau Date: Wed, 18 Oct 2023 11:23:53 -0700 Subject: [PATCH net 2/5] tcp: check mptcp-level constraints for backlog coalescing 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: <20231018-send-net-20231018-v1-2-17ecb002e41d@kernel.org> References: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> In-Reply-To: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> To: Matthieu Baerts , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Davide Caratti , Christoph Paasch , Florian Westphal Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, Mat Martineau , stable@vger.kernel.org X-Mailer: b4 0.12.3 From: Paolo Abeni The MPTCP protocol can acquire the subflow-level socket lock and cause the tcp backlog usage. When inserting new skbs into the backlog, the stack will try to coalesce them. Currently, we have no check in place to ensure that such coalescing will respect the MPTCP-level DSS, and that may cause data stream corruption, as reported by Christoph. Address the issue by adding the relevant admission check for coalescing in tcp_add_backlog(). Note the issue is not easy to reproduce, as the MPTCP protocol tries hard to avoid acquiring the subflow-level socket lock. Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Cc: stable@vger.kernel.org Reported-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/420 Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau --- net/ipv4/tcp_ipv4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index 27140e5cdc06..4167e8a48b60 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -1869,6 +1869,7 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff = *skb, #ifdef CONFIG_TLS_DEVICE tail->decrypted !=3D skb->decrypted || #endif + !mptcp_skb_can_collapse(tail, skb) || thtail->doff !=3D th->doff || memcmp(thtail + 1, th + 1, hdrlen - sizeof(*th))) goto no_coalesce; --=20 2.41.0 From nobody Sat May 11 21:38:34 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C7D741779; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RI3Znzzh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A7FDC433CB; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697653443; bh=sVVaA7qK6A1MF9I/eIxto2nwaRUVaUAUafSQEMrzHWU=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=RI3ZnzzhtoFKusIBwr/VslDUMaUBkWg/Avgof7QIE7W9NZvb8BT8tpbVOlvajYYgL hb4kafXQvUcXDh/AjYX/ax2UyuiRrCb/e+u8KB8kfDgFYMmGMqKU+ESsu7b8zvoDon /qgUBS+m08/d/O870whqig0ZgmhHOAL+WtzFIrkpU6D4EILB9pUyJMZbvTBgQL04I6 YJxHI/rUB7EY32VVE96NX/xGIqPcS5xbkqYju1oogY0MIAL7sqh0xOU5xTgEy+XSSj IEoDrLaLrp2aRGbwRK87QplwU3OVDTmOhTMh9X8hG/7moBdk5tzS9WYBuyNxNHGvYT VhbKEUaylQzrQ== From: Mat Martineau Date: Wed, 18 Oct 2023 11:23:54 -0700 Subject: [PATCH net 3/5] mptcp: more conservative check for zero probes 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: <20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org> References: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> In-Reply-To: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> To: Matthieu Baerts , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Davide Caratti , Christoph Paasch , Florian Westphal Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, Mat Martineau , stable@vger.kernel.org X-Mailer: b4 0.12.3 From: Paolo Abeni Christoph reported that the MPTCP protocol can find the subflow-level write queue unexpectedly not empty while crafting a zero-window probe, hitting a warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0x= c06/0xe70 Modules linked in: CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04= /01/2014 Workqueue: events mptcp_worker RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312 RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00 RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580 R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200 FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0 Call Trace: __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391 release_sock+0xf6/0x100 net/core/sock.c:3521 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784 kthread+0x143/0x180 kernel/kthread.c:388 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304 The root cause of the issue is that expectations are wrong: e.g. due to MPTCP-level re-injection we can hit the critical condition. Explicitly avoid the zero-window probe when the subflow write queue is not empty and drop the related warnings. Reported-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/444 Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau --- net/mptcp/protocol.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index d1902373c974..4e30e5ba3795 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1298,7 +1298,7 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct= sock *ssk, if (copy =3D=3D 0) { u64 snd_una =3D READ_ONCE(msk->snd_una); =20 - if (snd_una !=3D msk->snd_nxt) { + if (snd_una !=3D msk->snd_nxt || tcp_write_queue_tail(ssk)) { tcp_remove_empty_skb(ssk); return 0; } @@ -1306,11 +1306,6 @@ static int mptcp_sendmsg_frag(struct sock *sk, struc= t sock *ssk, zero_window_probe =3D true; data_seq =3D snd_una - 1; copy =3D 1; - - /* all mptcp-level data is acked, no skbs should be present into the - * ssk write queue - */ - WARN_ON_ONCE(reuse_skb); } =20 copy =3D min_t(size_t, copy, info->limit - info->sent); @@ -1339,7 +1334,6 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct= sock *ssk, if (reuse_skb) { TCP_SKB_CB(skb)->tcp_flags &=3D ~TCPHDR_PSH; mpext->data_len +=3D copy; - WARN_ON_ONCE(zero_window_probe); goto out; } =20 --=20 2.41.0 From nobody Sat May 11 21:38:34 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F6A44177B; Wed, 18 Oct 2023 18:24:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jk+4E41E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEE29C433BB; Wed, 18 Oct 2023 18:24:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697653444; bh=t3JO7pRjalAV5hLmRWEH40gfq1UpKK71NZeBrKPyjZw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Jk+4E41EHF7J+cpx8/j+4/hb+6adn6mFoDsvppVDqd+mvYF60l5Yo2yTDq14gJHN8 KZ4X67tmi+F4ruFvCK0Om7s6Teil0Imo61S0oXO5wLzGMH5FpaiBB8iDJwfdosy7x1 F6kw+UljXajFbdina45Hks3zVkLeBek8HxqijwUR7rrbpNorbeUqBKt95WrZTldFkj lMrdbHpgnizg5keYWt7fTyRO+v5QUeeP8nGah+BzPwL6W5lZIU/n/wCaNA/EOLoJwC Y0RVkd79MZoOjFJsqr35Lx+HwXgGym0KbgoqnhV+xsyYT6DZRl5D+nX4B4/nqUXsA7 QTfeJDSD+DrYQ== From: Mat Martineau Date: Wed, 18 Oct 2023 11:23:55 -0700 Subject: [PATCH net 4/5] mptcp: avoid sending RST when closing the initial subflow Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20231018-send-net-20231018-v1-4-17ecb002e41d@kernel.org> References: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> In-Reply-To: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> To: Matthieu Baerts , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Davide Caratti , Christoph Paasch , Florian Westphal Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , stable@vger.kernel.org X-Mailer: b4 0.12.3 From: Geliang Tang When closing the first subflow, the MPTCP protocol unconditionally calls tcp_disconnect(), which in turn generates a reset if the subflow is established. That is unexpected and different from what MPTCP does with MPJ subflows, where resets are generated only on FASTCLOSE and other edge scenarios. We can't reuse for the first subflow the same code in place for MPJ subflows, as MPTCP clean them up completely via a tcp_close() call, while must keep the first subflow socket alive for later re-usage, due to implementation constraints. This patch adds a new helper __mptcp_subflow_disconnect() that encapsulates, a logic similar to tcp_close, issuing a reset only when the MPTCP_CF_FASTCLOSE flag is set, and performing a clean shutdown otherwise. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: stable@vger.kernel.org Reviewed-by: Matthieu Baerts Co-developed-by: Paolo Abeni Signed-off-by: Paolo Abeni Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau --- net/mptcp/protocol.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 4e30e5ba3795..886ab689a8ae 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2348,6 +2348,26 @@ bool __mptcp_retransmit_pending_data(struct sock *sk) #define MPTCP_CF_PUSH BIT(1) #define MPTCP_CF_FASTCLOSE BIT(2) =20 +/* be sure to send a reset only if the caller asked for it, also + * clean completely the subflow status when the subflow reaches + * TCP_CLOSE state + */ +static void __mptcp_subflow_disconnect(struct sock *ssk, + struct mptcp_subflow_context *subflow, + unsigned int flags) +{ + if (((1 << ssk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN)) || + (flags & MPTCP_CF_FASTCLOSE)) { + /* The MPTCP code never wait on the subflow sockets, TCP-level + * disconnect should never fail + */ + WARN_ON_ONCE(tcp_disconnect(ssk, 0)); + mptcp_subflow_ctx_reset(subflow); + } else { + tcp_shutdown(ssk, SEND_SHUTDOWN); + } +} + /* subflow sockets can be either outgoing (connect) or incoming * (accept). * @@ -2385,7 +2405,7 @@ static void __mptcp_close_ssk(struct sock *sk, struct= sock *ssk, lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); =20 if ((flags & MPTCP_CF_FASTCLOSE) && !__mptcp_check_fallback(msk)) { - /* be sure to force the tcp_disconnect() path, + /* be sure to force the tcp_close path * to generate the egress reset */ ssk->sk_lingertime =3D 0; @@ -2395,11 +2415,7 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, =20 need_push =3D (flags & MPTCP_CF_PUSH) && __mptcp_retransmit_pending_data(= sk); if (!dispose_it) { - /* The MPTCP code never wait on the subflow sockets, TCP-level - * disconnect should never fail - */ - WARN_ON_ONCE(tcp_disconnect(ssk, 0)); - mptcp_subflow_ctx_reset(subflow); + __mptcp_subflow_disconnect(ssk, subflow, flags); release_sock(ssk); =20 goto out; --=20 2.41.0 From nobody Sat May 11 21:38:34 2024 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFEB941AB9; Wed, 18 Oct 2023 18:24:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qgHppDzn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 254BFC433BF; Wed, 18 Oct 2023 18:24:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697653444; bh=KZ6N65Nkl5YNxcN1w6vYt0uy5Mo7hWRtrXVthBvScVQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=qgHppDzn1lteN27ftYSRGn1OItTRhdHkeXOxxWx3DlIhx2Z4kqwxj56FDfE7Z4WAs 5r1ytCFEPMxUiKwTWXeOIBxjyOH00RfS1S3JZrUt2pC6yUs9WmpGYf3JRGRYv93+9W Srjd0CY6+A6JoOe46C6oOfemi2d3H+Tmckq0GkDCv53G4wxNblQnK1HOsXae+7H0t3 4fP0ZpvqYbtqGXEGN36rGj6ykYTlhHRyVnfqZE2H/if6lN1eJtSzax3qXYnw/xZXJn UTG1B7v0gWze0fQKWkpW7gmaO6Ivjmh8SjEU22nH7UhVFaRtslZfsixec/oVlYMbHC ij4MjqjEneoWg== From: Mat Martineau Date: Wed, 18 Oct 2023 11:23:56 -0700 Subject: [PATCH net 5/5] selftests: mptcp: join: no RST when rm subflow/addr 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: <20231018-send-net-20231018-v1-5-17ecb002e41d@kernel.org> References: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> In-Reply-To: <20231018-send-net-20231018-v1-0-17ecb002e41d@kernel.org> To: Matthieu Baerts , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern , Davide Caratti , Christoph Paasch , Florian Westphal Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, Mat Martineau , stable@vger.kernel.org X-Mailer: b4 0.12.3 From: Matthieu Baerts Recently, we noticed that some RST were wrongly generated when removing the initial subflow. This patch makes sure RST are not sent when removing any subflows or any addresses. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: stable@vger.kernel.org Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index 27953670206e..dc895b7b94e1 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -2309,6 +2309,7 @@ remove_tests() chk_join_nr 1 1 1 chk_rm_tx_nr 1 chk_rm_nr 1 1 + chk_rst_nr 0 0 fi =20 # multiple subflows, remove @@ -2321,6 +2322,7 @@ remove_tests() run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 2 2 2 chk_rm_nr 2 2 + chk_rst_nr 0 0 fi =20 # single address, remove @@ -2333,6 +2335,7 @@ remove_tests() chk_join_nr 1 1 1 chk_add_nr 1 1 chk_rm_nr 1 1 invert + chk_rst_nr 0 0 fi =20 # subflow and signal, remove @@ -2346,6 +2349,7 @@ remove_tests() chk_join_nr 2 2 2 chk_add_nr 1 1 chk_rm_nr 1 1 + chk_rst_nr 0 0 fi =20 # subflows and signal, remove @@ -2360,6 +2364,7 @@ remove_tests() chk_join_nr 3 3 3 chk_add_nr 1 1 chk_rm_nr 2 2 + chk_rst_nr 0 0 fi =20 # addresses remove @@ -2374,6 +2379,7 @@ remove_tests() chk_join_nr 3 3 3 chk_add_nr 3 3 chk_rm_nr 3 3 invert + chk_rst_nr 0 0 fi =20 # invalid addresses remove @@ -2388,6 +2394,7 @@ remove_tests() chk_join_nr 1 1 1 chk_add_nr 3 3 chk_rm_nr 3 1 invert + chk_rst_nr 0 0 fi =20 # subflows and signal, flush @@ -2402,6 +2409,7 @@ remove_tests() chk_join_nr 3 3 3 chk_add_nr 1 1 chk_rm_nr 1 3 invert simult + chk_rst_nr 0 0 fi =20 # subflows flush @@ -2421,6 +2429,7 @@ remove_tests() else chk_rm_nr 3 3 fi + chk_rst_nr 0 0 fi =20 # addresses flush @@ -2435,6 +2444,7 @@ remove_tests() chk_join_nr 3 3 3 chk_add_nr 3 3 chk_rm_nr 3 3 invert simult + chk_rst_nr 0 0 fi =20 # invalid addresses flush @@ -2449,6 +2459,7 @@ remove_tests() chk_join_nr 1 1 1 chk_add_nr 3 3 chk_rm_nr 3 1 invert + chk_rst_nr 0 0 fi =20 # remove id 0 subflow @@ -2460,6 +2471,7 @@ remove_tests() run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 chk_rm_nr 1 1 + chk_rst_nr 0 0 fi =20 # remove id 0 address @@ -2472,6 +2484,7 @@ remove_tests() chk_join_nr 1 1 1 chk_add_nr 1 1 chk_rm_nr 1 1 invert + chk_rst_nr 0 0 invert fi } =20 --=20 2.41.0