From patchwork Fri Aug 9 12:37:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthieu Baerts X-Patchwork-Id: 13758755 X-Patchwork-Delegate: matthieu.baerts@tessares.net 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 3638E1DFF5 for ; Fri, 9 Aug 2024 12:38:04 +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=1723207085; cv=none; b=YOQ9P8km2q9Iy3sXG97Ked0XerPkwAaca0lg0/rgu3dgF6oO7Hpit0X/KGfSdOANtuV+BfN+cIQRuX28HXUlkG97FHmR3HQVCAlinbdQ7ZmlFvawrRd0mARO/dfkYlfT1qLrYZuZ4vO70X7FFDgMCbej6E9fQJpLaGIVQOSebGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723207085; c=relaxed/simple; bh=5VnEQ7lL31LgxTCTmas2JNcabMLme32mKIxTeFksTd4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=aRKGyn3lsRn8HUuvLe6nDPYZP6v7usTILq82MGdypmNogB+ub6MdHdDOolrQqbpFZe8NeYi3kwUbgUZI1+JNuk49jd71DFGMBOLPsbXZ23pMEj4xdFsrTBlQ7etIrpQ5vPiTn9HjZLwdjN0IqegWA4IuuAE+1yNUe5h1HZR1hxA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=brIpLkmv; 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="brIpLkmv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 148FAC4AF0B; Fri, 9 Aug 2024 12:38:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723207084; bh=5VnEQ7lL31LgxTCTmas2JNcabMLme32mKIxTeFksTd4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=brIpLkmvQhiC+pYzpd8Trs11xK1WVx5LZB2qFqO0YhIcYyigHYratCKne4KTGHEDx 5wE4Ty87qUhPtBSoUILZp3Sm1+g17ERvJb/Nbyk2cFXoGTqtJwPtBWGj918aeGi6Mk E/5oMfx0MozT3fVuIzHJCc4zz2gueUA9QtEiiYwvPWkEsLDOvOipjizJpsvSj320vX sqEfkhszVt7m4vhVuQPgRQXAtZu2RLMTmv9Zmkmr9nNR0fcj2dboehRutnYfZGKZJ+ h/MI2/jr00lVFCBNs6TOTZmIB7jmf2FxqN20Kh7Nr3C5TPtF/qmHSsl+Wcqi9ISzlB bnEwLTQSGmd+g== From: "Matthieu Baerts (NGI0)" Date: Fri, 09 Aug 2024 14:37:49 +0200 Subject: [PATCH mptcp-net v7 1/3] mptcp: close subflow when receiving TCP+FIN Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240809-mptcp-pm-avail-v7-1-3d0916ba39b4@kernel.org> References: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> In-Reply-To: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> To: mptcp@lists.linux.dev Cc: Mat Martineau , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=3234; i=matttbe@kernel.org; h=from:subject:message-id; bh=5VnEQ7lL31LgxTCTmas2JNcabMLme32mKIxTeFksTd4=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmtg2qc6wkbX28uL5/F3MtFPnqNpCVLZRVFewuy 24ArIuRzSCJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZrYNqgAKCRD2t4JPQmmg cxdCD/9hN7IICTT4hF1szbKYjqwaF+xf/zkd+xLy4xhudyJTYSfapipBXEeMatgfZocpZRtmzsL dyXH98QcuqidUhmj/XPg2nyX/TZBOeooi3fsTLaGMmHQgAehwQRfOsUPVPz5x9riIEioLFPum+Q 2mg+BVHKuLY4wYa5zGONtWQlY2wdf3z7c3l6DoLW+6G6xYV/aJgko4hDjyU6weR797FhaZBnnYU SWOg7mz3kkhp2rsQCSzx48xOdEXerAv3RDCciLWUDuvLBrJTg3ER8enaPiv5f1CBO2RluF7xsJW 0pEfN93HNQt8jqQ7HAHIxoRVL+sfRmoepZ8XYKX+xEiJ1u1CVGVvbpxMOvgMYscIGDhvHgHmAtj hm6nTCq0GP+z042yC8iqOhMDsfMSOhFWTgGm3+w+zTRLpoXNXREXWNgh9dA0Seca5j72gUG3eOR sfeEnZwefI/3D+QDutBQglDcckElSShbNYrVoMwNzUN7z5/E4enoStwYjBp6d99NIBMiqpZQzn0 CPy+PGpIQdOLPN5MXEGIDX+pE3l5k4XrSh3YeKwnq0r7ZLCs2DDSW+o/mbbJnLbpnT/5waAl6V5 v16W5kgcsdjnqazD6DXf/dp8iYisLuJ/77Z9wnvn0IjORyytL4c9vERhpnx0OKUI1j+o2jlNKs1 aFCAd0sejJpDsKQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When a peer decides to close one subflow in the middle of a connection having multiple subflows, the receiver of the first FIN should accept that, and close the subflow on its side as well. If not, the subflow will stay half closed, and would even continue to be used until the end of the MPTCP connection or a reset from the network. The issue has not been seen before, probably because the in-kernel path-manager always sends a RM_ADDR before closing the subflow. Upon the reception of this RM_ADDR, the other peer will initiate the closure on its side as well. On the other hand, if the RM_ADDR is lost, or if the path-manager of the other peer only closes the subflow without sending a RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it, leaving the subflow half-closed. So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if the MPTCP connection has not been closed before with a DATA_FIN, the kernel owning the subflow schedules its worker to initiate the closure on its side as well. This issue can be easily reproduced with packetdrill, as visible in [1], by creating an additional subflow, injecting a FIN+ACK before sending the DATA_FIN, and expecting a FIN+ACK in return. Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed") Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1] Signed-off-by: Matthieu Baerts (NGI0) --- Notes: - v7: - use ssk_state instead of ssk->sk_state. (Mat) --- net/mptcp/protocol.c | 5 ++++- net/mptcp/subflow.c | 8 ++++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 13777c35496c..9ad48c798144 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2533,8 +2533,11 @@ static void __mptcp_close_subflow(struct sock *sk) mptcp_for_each_subflow_safe(msk, subflow, tmp) { struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + int ssk_state = inet_sk_state_load(ssk); - if (inet_sk_state_load(ssk) != TCP_CLOSE) + if (ssk_state != TCP_CLOSE && + (ssk_state != TCP_CLOSE_WAIT || + inet_sk_state_load(sk) != TCP_ESTABLISHED)) continue; /* 'subflow_data_ready' will re-sched once rx queue is empty */ diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index a7fb4d46e024..723cd3fbba32 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1255,12 +1255,16 @@ static void mptcp_subflow_discard_data(struct sock *ssk, struct sk_buff *skb, /* sched mptcp worker to remove the subflow if no more data is pending */ static void subflow_sched_work_if_closed(struct mptcp_sock *msk, struct sock *ssk) { - if (likely(ssk->sk_state != TCP_CLOSE)) + struct sock *sk = (struct sock *)msk; + + if (likely(ssk->sk_state != TCP_CLOSE && + (ssk->sk_state != TCP_CLOSE_WAIT || + inet_sk_state_load(sk) != TCP_ESTABLISHED))) return; if (skb_queue_empty(&ssk->sk_receive_queue) && !test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags)) - mptcp_schedule_work((struct sock *)msk); + mptcp_schedule_work(sk); } static bool subflow_can_fallback(struct mptcp_subflow_context *subflow) From patchwork Fri Aug 9 12:37:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthieu Baerts X-Patchwork-Id: 13758756 X-Patchwork-Delegate: matthieu.baerts@tessares.net 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 1CA1C1DFF5 for ; Fri, 9 Aug 2024 12:38:06 +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=1723207086; cv=none; b=FDjsk3ULixxzSTjo2bMcybSRz44kLJ8uc+FMFY6uQvjo249qKq40kDpV7kkZfxnZcy16t8XXBtgGeMfAWMzGlI2EPCsKVYoOP4m6TZFfK+UVStTFbyPt4YVakpubJDGX81aSKxjTLUGofoG9yrgGVZrKopq1bz71qIGXZOIDrlc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723207086; c=relaxed/simple; bh=wIOiFg8BmC5bNKfY7OrATgmbrxlQMpRLLp4QjsGPk44=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=c2BNYqFV/1/EwHOZ/uQkDmBcHX5b/nJSX8E9JU4rkFWLSPqaY1v/U/4HnmBrc4xPE0mAL9ZiAtUg7VlGjXqgl7zm0/WrEmFbCsf2NJlOIIAF2wsnngxnT181ba6oUn0NPrsRoHF99WxryCU7m024lvEsq2grfqFrVXT/3tbB04Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TUS3RZTI; 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="TUS3RZTI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40597C4AF0F; Fri, 9 Aug 2024 12:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723207086; bh=wIOiFg8BmC5bNKfY7OrATgmbrxlQMpRLLp4QjsGPk44=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=TUS3RZTI0JC3dQFdU5IIa0KTnIsETmPrb3zLsQHVODsLWa21FpkaJZvJ85IOSv8xw R4rM8jmGM041+fxapDQBT2iclHjYWji/z8RjAuiiuO7+1XBGiAlv8nxnnCW1+Sdo6o 8GNXmMFWQdNJ7Z5KrrO12Pbak+zEYt0vceLQDd/639xTBAX1P5Xv76QWtWwQR7EgHB Qm9fUZjd2D+XMJEMU0x9WhFCo1u1e3XUf8bKuEtUaQnaKuH6reCfrDWjlZ8QQ5LALL GydSU0dzS8ZgMPdxQ4B85LEdu4ZxGpbd/fibsQ2uT2O3QJaX61XhC9RvOLIsKix7cq J2QpVVgJ/EyJA== From: "Matthieu Baerts (NGI0)" Date: Fri, 09 Aug 2024 14:37:50 +0200 Subject: [PATCH mptcp-net v7 2/3] selftests: mptcp: join: cannot rm sf if closed Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240809-mptcp-pm-avail-v7-2-3d0916ba39b4@kernel.org> References: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> In-Reply-To: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> To: mptcp@lists.linux.dev Cc: Mat Martineau , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=3317; i=matttbe@kernel.org; h=from:subject:message-id; bh=wIOiFg8BmC5bNKfY7OrATgmbrxlQMpRLLp4QjsGPk44=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmtg2q1Sehvai+p8aJDEkecmK8eEoV7Ndrooh73 A5L3+vpQn6JAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZrYNqgAKCRD2t4JPQmmg c8NqD/4zG2KEg/YKeHman+SF2Nfx0nRe02Ot9Ds85z5FaDLzMrDhDHpvZTVvyrpvUEbLBgQ1sDS lk6sWdR7pmYWtfWtou+fl3YtD1JAnH27JxO3JMfidifV3TLDXKLLUA0ZZ8ekBPbIbu+zVAeEraw 1SxWnSK08K+P34fRMevbf40d9soEggTCtMvu2N4THeCNvEVhN8D64GkL/UW8vCTONq0Ujx6TWTM mhTX5KZgm1/ABkFuC5S6j5A62m4glP8g/OMpyaHC+ytVPjUnP/Kk9L2/+n7PgHeXGDyQagdjWJa hlNcTsDg0E7LQsS9GwQ3b2tyFn37s4r1Ov91dWioC6soKx2lux+HkM8tswKoZdaAZgFbSNguYzM FlGPgw/QBY0hD+SuwohIOJFRubGsbc0IiJFaILzGt56tjIJr4nJZ5wZjGuEc5c/mO7MgV36hha3 dtqrlEnWW3PKt97/n8cGE/e7lzcI+T39v8tSi5ULzkVt+exKUX5nQZ7Iq98hrDMLip1SeYItak8 TI04WpP4leluBm2SHwTQUyLln2IxPvhXBU10mltMen4CpPSnce7ndICeiQclptyUFZ1SQ/M0Nyy pHRxZeqbLfpHWo3YakeBBoxZwkJuJow71Rx31TgRcWNlg51V4gJHItlBWBViaKzkWIcobFoj9E0 KqHWNdrVx5KG7EA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Thanks to the previous commit, the MPTCP subflows are now closed on both directions even when only the MPTCP path-manager of one peer asks for their closure. In the two tests modified here -- "userspace pm add & remove address" and "userspace pm create destroy subflow" -- one peer is controlled by the userspace PM, and the other one by the in-kernel PM. When the userspace PM sends a RM_ADDR notification, the in-kernel PM will automatically react by closing all subflows using this address. Now, thanks to the previous commit, the subflows are properly closed on both directions, the userspace PM can then no longer closes the same subflows if they are already closed. Before, it was OK to do that, because the subflows were still half-opened, still OK to send a RM_ADDR. In other words, thanks to the previous commit closing the subflows, an error will be returned to the userspace if it tries to close a subflow that has already been closed. So no need to run this command, which mean that the linked counters will then not be incremented. These tests are then no longer sending both a RM_ADDR, then closing the linked subflow just after. The test with the userspace PM on the server side is now removing one subflow linked to one address, then sending a RM_ADDR for another address. The test with the userspace PM on the client side is now only removing the subflow that was previously created. Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") Signed-off-by: Matthieu Baerts (NGI0) --- Notes: - v7: - clarify behaviour without the previous patch. (Mat) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index ea954ba85969..4129952fd9ec 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -3408,14 +3408,12 @@ userspace_tests() "signal" userspace_pm_chk_get_addr "${ns1}" "10" "id 10 flags signal 10.0.2.1" userspace_pm_chk_get_addr "${ns1}" "20" "id 20 flags signal 10.0.3.1" - userspace_pm_rm_addr $ns1 10 userspace_pm_rm_sf $ns1 "::ffff:10.0.2.1" $MPTCP_LIB_EVENT_SUB_ESTABLISHED userspace_pm_chk_dump_addr "${ns1}" \ - "id 20 flags signal 10.0.3.1" "after rm_addr 10" + "id 20 flags signal 10.0.3.1" "after rm_sf 10" userspace_pm_rm_addr $ns1 20 - userspace_pm_rm_sf $ns1 10.0.3.1 $MPTCP_LIB_EVENT_SUB_ESTABLISHED userspace_pm_chk_dump_addr "${ns1}" "" "after rm_addr 20" - chk_rm_nr 2 2 invert + chk_rm_nr 1 1 invert chk_mptcp_info subflows 0 subflows 0 chk_subflows_total 1 1 kill_events_pids @@ -3439,12 +3437,11 @@ userspace_tests() "id 20 flags subflow 10.0.3.2" \ "subflow" userspace_pm_chk_get_addr "${ns2}" "20" "id 20 flags subflow 10.0.3.2" - userspace_pm_rm_addr $ns2 20 userspace_pm_rm_sf $ns2 10.0.3.2 $MPTCP_LIB_EVENT_SUB_ESTABLISHED userspace_pm_chk_dump_addr "${ns2}" \ "" \ - "after rm_addr 20" - chk_rm_nr 1 1 + "after rm_sf 20" + chk_rm_nr 0 1 chk_mptcp_info subflows 0 subflows 0 chk_subflows_total 1 1 kill_events_pids From patchwork Fri Aug 9 12:37:51 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthieu Baerts X-Patchwork-Id: 13758757 X-Patchwork-Delegate: matthieu.baerts@tessares.net 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 54B361DFF5 for ; Fri, 9 Aug 2024 12:38:07 +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=1723207087; cv=none; b=e7N83wJbPqxzzYJJr6jbgNS2v76fG0BfTUxUKQ3wAqsB9RGvg5/j5ztDTY/IvAsBsiYxK48r7QtPX8OhDXU5H2RJet2i92f6saRuaBgVCI2eXf5pbobqW/wFJcKhRbg2oeI7plmjpAnitH53+EgBzUGzrqr/OG6/ltdxMfcrFL4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723207087; c=relaxed/simple; bh=yp/Q21clBvVf3+sFMcwbOZwek33y3rt9IXlTHmsPK5Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=NDekrjjvU41Tzc8C5ykl21q7t/chUrcxkcZp9/+BARFixFT2RfElRHHLz0quUSpPjOvJnUcH0Uxr+q70fulpjgweyVb98Fns/CJTqesL3H9tRt5KYe7xLVxBcxWwJmZuTbYetZBwpPR9jS+k53l6DXxZMG7cN500FNJWzKy/nCM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cM8EfDi5; 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="cM8EfDi5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DACCC32782; Fri, 9 Aug 2024 12:38:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723207087; bh=yp/Q21clBvVf3+sFMcwbOZwek33y3rt9IXlTHmsPK5Y=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=cM8EfDi5hCFtyWwNUWgS4dnnV8U+WLcIq2vMv52hua9yDfFrT0hk9HHJvGmEoM3Oq WwI+heruwxrtW2Jo8fkDIUpgFb7X79769rmMeMYh8oMdxdllDxqolw9fpTdKIncfLQ XufIhy3PseVyMY35IDqnKq4vrc0zfPncmCaS0Df+r7w+7ny1Av1sA4wrHgN4XFqw7U x5oIOBzKIQjHncussbn2Xzm/JmUi2w1TE6V/GSUFlRN7s9O1Qb1amseBBhvW5Yiaj2 onbX2R+BNY6wM3g8nlGl6WSSMZmA9HYEMxs4+NV4nJTulxPY60HiRvJ7V2bRHTU78o uUTGPKJJBy9ag== From: "Matthieu Baerts (NGI0)" Date: Fri, 09 Aug 2024 14:37:51 +0200 Subject: [PATCH mptcp-net v7 3/3] mptcp: pm: send ACK on non stale subflows Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240809-mptcp-pm-avail-v7-3-3d0916ba39b4@kernel.org> References: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> In-Reply-To: <20240809-mptcp-pm-avail-v7-0-3d0916ba39b4@kernel.org> To: mptcp@lists.linux.dev Cc: Mat Martineau , "Matthieu Baerts (NGI0)" X-Mailer: b4 0.14.1 X-Developer-Signature: v=1; a=openpgp-sha256; l=1728; i=matttbe@kernel.org; h=from:subject:message-id; bh=yp/Q21clBvVf3+sFMcwbOZwek33y3rt9IXlTHmsPK5Y=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBmtg2qSdL8C17k2bfOgnPhAFtTRvEJhzMzT6lvL t6fY6hb+8yJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZrYNqgAKCRD2t4JPQmmg cxTjEAClp8WRvn2PI31tC0Aeq7XIIFk/OOIOaxeZziJy8Hi02t0viDgSyyXfMIBCaMHWOtOe2ex LSg3+6YZ14LEK5fbnsfkblpPHWsrKDUrGO/z6EcdUUJF9aiUGzbreD6AWWvIi/hYT7Ts6JQdJvK rTO1CAA6BGGkt2ZycdhnFL/GYjZBRBrilWnQwebm0tDsXt1L0i0sQ8JAqes7Yxgiu6BtdO7B2if 3gtDyBYG65eo4PH39i/hvVoQ8kzgJJdEykJfWmLxsBwHGLhHBc2Y+EFfMSOls8C0Fu3OpQ3GXGx BTmkH2lKKpaktg8mG3gvMw2MTVr/0EKJnzN/5W9fI6eM4dnbB7Em+Oo0q9+bvHWlELpLQxT3v4E lyuu8ZPgPaYRAzaP+24kWM9HbIQnrNDJKXdMBwPG8+UAr4tPADk0Z+FKXYVYb18v/vc53WkimC8 Gj9VHuZ8MrwoK3wiYXNdsFvB8iwfPObT35FYKdMMjd2lKrbbc9JCPOVmA2y9JtdHDyhfyNENqt1 ADWkmX/IJXv1zQNMZcEULZX+E6WfGDJWkCxvB8+lE7q0kv06JYvK+wL5RKOR/Lq5It7qkjqwRyh 8hk41Yoa4Hr7OEBrAVTNIJoFlJzvxWsLqh6dOmsQreCWGlpaKzE0UwwddnUt2r5H8nEO17ibF1F jAIsP55kYl2s/ww== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 If the subflow is considered as "staled", it is better to avoid it to send an ACK carrying an ADD_ADDR or RM_ADDR. Another subflow, if any, will then be selected. Signed-off-by: Matthieu Baerts (NGI0) --- Notes: - It sounds safer to do this modification in -next. I also wonder if we should not add more check, e.g. not on backup flow except if there are no other non-backup ones, or still pick a staled one if there are no others, etc. But maybe we don't need to care for an ACK? And we can always improve that later! - v7: - Include the Squash-to patch. (Mat) --- net/mptcp/pm_netlink.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index d3b1b459e6f3..3bdb0219188f 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -762,7 +762,7 @@ static void mptcp_pm_nl_add_addr_received(struct mptcp_sock *msk) void mptcp_pm_nl_addr_send_ack(struct mptcp_sock *msk) { - struct mptcp_subflow_context *subflow; + struct mptcp_subflow_context *subflow, *alt = NULL; msk_owned_by_me(msk); lockdep_assert_held(&msk->pm.lock); @@ -773,10 +773,18 @@ void mptcp_pm_nl_addr_send_ack(struct mptcp_sock *msk) mptcp_for_each_subflow(msk, subflow) { if (__mptcp_subflow_active(subflow)) { - mptcp_pm_send_ack(msk, subflow, false, false); - break; + if (!subflow->stale) { + mptcp_pm_send_ack(msk, subflow, false, false); + return; + } + + if (!alt) + alt = subflow; } } + + if (alt) + mptcp_pm_send_ack(msk, alt, false, false); } int mptcp_pm_nl_mp_prio_send_ack(struct mptcp_sock *msk,