FAILED: patch "[PATCH] mptcp: fix duplicate reset on fastclose" failed to apply to 6.6-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x ae155060247be8dcae3802a95bd1bdf93ab3215d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2025112433-making-debatable-abfe@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ae155060247be8dcae3802a95bd1bdf93ab3215d Mon Sep 17 00:00:00 2001
From: Paolo Abeni <[email protected]>
Date: Tue, 18 Nov 2025 08:20:24 +0100
Subject: [PATCH] mptcp: fix duplicate reset on fastclose
The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter.
Indeed there is window of opportunity at fastclose time for the following race:
mptcp_do_fastclose
__mptcp_close_ssk
__tcp_close()
tcp_set_state() [1]
tcp_send_active_reset() [2]After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2].
Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status.
net/mptcp/protocol.c +23 -13
@@ -2409,7 +2409,6 @@ bool __mptcp_retransmit_pending_data(struct sock *sk)/* flags for __mptcp_close_ssk() */ #define MPTCP_CF_PUSH BIT(1) -#define MPTCP_CF_FASTCLOSE BIT(2)/* be sure to send a reset only if the caller asked for it, also * clean completely the subflow status when the subflow reaches
@@ -2420,7 +2419,7 @@ static void __mptcp_subflow_disconnect(struct sock *ssk, unsigned int flags) {if (((1 << ssk->sk_state) & (TCPF_CLOSE |TCPF_LISTEN )) || - (flags &MPTCP_CF_FASTCLOSE )) { + subflow->send_fastclose) {/* The MPTCP code never wait on the subflow sockets, TCP-level * disconnect should never fail */
@@ -2467,14 +2466,8 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,lock_sock_nested (ssk,SINGLE_DEPTH_NESTING ); -if ((flags &MPTCP_CF_FASTCLOSE ) && !__mptcp_check_fallback (msk)) { -/* be sure to force the tcp_close path -* to generate the egress reset -*/ - ssk->sk_lingertime =0 ; -sock_set_flag (ssk,SOCK_LINGER ); - subflow->send_fastclose =1 ; - } +if (subflow->send_fastclose && ssk->sk_state !=TCP_CLOSE ) +tcp_set_state (ssk,TCP_CLOSE ); need_push = (flags &MPTCP_CF_PUSH ) &&__mptcp_retransmit_pending_data (sk);if (!dispose_it) {
@@ -2779,9 +2772,26 @@ static void mptcp_do_fastclose(struct sock *sk)struct mptcp_sock *msk =mptcp_sk (sk);mptcp_set_state (sk,TCP_CLOSE ); -mptcp_for_each_subflow_safe (msk, subflow, tmp) -__mptcp_close_ssk (sk,mptcp_subflow_tcp_sock (subflow), - subflow,MPTCP_CF_FASTCLOSE ); + +/* Explicitly send the fastclose reset as need */ +if (__mptcp_check_fallback (msk)) +return ; + +mptcp_for_each_subflow_safe (msk, subflow, tmp) { +struct sock *ssk =mptcp_subflow_tcp_sock (subflow); + +lock_sock (ssk); + +/* Some subflow socket states don't allow/need a reset.*/ +if ((1 << ssk->sk_state) & (TCPF_LISTEN |TCPF_CLOSE )) + goto unlock; + + subflow->send_fastclose =1 ; +tcp_send_active_reset (ssk, ssk->sk_allocation, +SK_RST_REASON_TCP_ABORT_ON_CLOSE ); +unlock: +release_sock (ssk); + } }static void mptcp_worker (struct work_struct *work)
Matthieu Baerts (NGI0)
maintainerPATCH 1/1 mptcp: fix duplicate reset on fastclose
From: Paolo Abeni <[email protected]>
commit ae155060247be8dcae3802a95bd1bdf93ab3215d upstream.
The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter.
Indeed there is window of opportunity at fastclose time for the following race:
mptcp_do_fastclose
__mptcp_close_ssk
__tcp_close()
tcp_set_state() [1]
tcp_send_active_reset() [2]After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2].
Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status.
[ No conflicts, but tcp_send_active_reset() doesn't take a 3rd argument
(sk_rst_reason) in this version, see commit 5691276b39da ("rstreason:
prepare for active reset"). This argument is only helpful for tracing, it is fine to drop it. ]
--- net/mptcp/protocol.c | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-)
net/mptcp/protocol.c +22 -13
@@ -2431,7 +2431,6 @@ bool __mptcp_retransmit_pending_data(struct sock *sk)/* flags for __mptcp_close_ssk() */ #define MPTCP_CF_PUSH BIT(1) -#define MPTCP_CF_FASTCLOSE BIT(2)/* be sure to send a reset only if the caller asked for it, also * clean completely the subflow status when the subflow reaches
@@ -2442,7 +2441,7 @@ static void __mptcp_subflow_disconnect(struct sock *ssk, unsigned int flags) {if (((1 << ssk->sk_state) & (TCPF_CLOSE |TCPF_LISTEN )) || - (flags &MPTCP_CF_FASTCLOSE )) { + subflow->send_fastclose) {/* The MPTCP code never wait on the subflow sockets, TCP-level * disconnect should never fail */
@@ -2489,14 +2488,8 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,lock_sock_nested (ssk,SINGLE_DEPTH_NESTING ); -if ((flags &MPTCP_CF_FASTCLOSE ) && !__mptcp_check_fallback (msk)) { -/* be sure to force the tcp_close path -* to generate the egress reset -*/ - ssk->sk_lingertime =0 ; -sock_set_flag (ssk,SOCK_LINGER ); - subflow->send_fastclose =1 ; - } +if (subflow->send_fastclose && ssk->sk_state !=TCP_CLOSE ) +tcp_set_state (ssk,TCP_CLOSE ); need_push = (flags &MPTCP_CF_PUSH ) &&__mptcp_retransmit_pending_data (sk);if (!dispose_it) {
@@ -2800,9 +2793,25 @@ static void mptcp_do_fastclose(struct sock *sk)struct mptcp_sock *msk =mptcp_sk (sk);mptcp_set_state (sk,TCP_CLOSE ); -mptcp_for_each_subflow_safe (msk, subflow, tmp) -__mptcp_close_ssk (sk,mptcp_subflow_tcp_sock (subflow), - subflow,MPTCP_CF_FASTCLOSE ); + +/* Explicitly send the fastclose reset as need */ +if (__mptcp_check_fallback (msk)) +return ; + +mptcp_for_each_subflow_safe (msk, subflow, tmp) { +struct sock *ssk =mptcp_subflow_tcp_sock (subflow); + +lock_sock (ssk); + +/* Some subflow socket states don't allow/need a reset.*/ +if ((1 << ssk->sk_state) & (TCPF_LISTEN |TCPF_CLOSE )) + goto unlock; + + subflow->send_fastclose =1 ; +tcp_send_active_reset (ssk, ssk->sk_allocation); +unlock: +release_sock (ssk); + } }static void mptcp_worker (struct work_struct *work)
Signature · 1 line
2.51.0
Patch "mptcp: fix duplicate reset on fastclose" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
mptcp: fix duplicate reset on fastclose
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mptcp-fix-duplicate-reset-on-fastclose.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
From [email protected] Thu Nov 27 19:28:04 2025
From: "Matthieu Baerts (NGI0)" <[email protected]>
Date: Thu, 27 Nov 2025 19:27:42 +0100
Subject: mptcp: fix duplicate reset on fastclose
To: [email protected], [email protected]
Cc: MPTCP Upstream <[email protected]>, Paolo Abeni <[email protected]>, Geliang Tang <[email protected]>, "Matthieu Baerts (NGI0)" <[email protected]>, Jakub Kicinski <[email protected]>
Message-ID: <[email protected]>
From: Paolo Abeni <[email protected]>
commit ae155060247be8dcae3802a95bd1bdf93ab3215d upstream.
The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter.
Indeed there is window of opportunity at fastclose time for the following race:
mptcp_do_fastclose
__mptcp_close_ssk
__tcp_close()
tcp_set_state() [1]
tcp_send_active_reset() [2]After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2].
Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status.
[ No conflicts, but tcp_send_active_reset() doesn't take a 3rd argument
(sk_rst_reason) in this version, see commit 5691276b39da ("rstreason:
prepare for active reset"). This argument is only helpful for tracing, it is fine to drop it. ]
--- net/mptcp/protocol.c | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-)
net/mptcp/protocol.c +22 -13
@@ -2431,7 +2431,6 @@ bool __mptcp_retransmit_pending_data(str/* flags for __mptcp_close_ssk() */ #define MPTCP_CF_PUSH BIT(1) -#define MPTCP_CF_FASTCLOSE BIT(2)/* be sure to send a reset only if the caller asked for it, also * clean completely the subflow status when the subflow reaches
@@ -2442,7 +2441,7 @@ static void __mptcp_subflow_disconnect(s unsigned int flags) {if (((1 << ssk->sk_state) & (TCPF_CLOSE |TCPF_LISTEN )) || - (flags &MPTCP_CF_FASTCLOSE )) { + subflow->send_fastclose) {/* The MPTCP code never wait on the subflow sockets, TCP-level * disconnect should never fail */
@@ -2489,14 +2488,8 @@ static void __mptcp_close_ssk(struct soclock_sock_nested (ssk,SINGLE_DEPTH_NESTING ); -if ((flags &MPTCP_CF_FASTCLOSE ) && !__mptcp_check_fallback (msk)) { -/* be sure to force the tcp_close path -* to generate the egress reset -*/ - ssk->sk_lingertime =0 ; -sock_set_flag (ssk,SOCK_LINGER ); - subflow->send_fastclose =1 ; - } +if (subflow->send_fastclose && ssk->sk_state !=TCP_CLOSE ) +tcp_set_state (ssk,TCP_CLOSE ); need_push = (flags &MPTCP_CF_PUSH ) &&__mptcp_retransmit_pending_data (sk);if (!dispose_it) {
@@ -2809,9 +2802,25 @@ static void mptcp_do_fastclose(struct sostruct mptcp_sock *msk =mptcp_sk (sk);mptcp_set_state (sk,TCP_CLOSE ); -mptcp_for_each_subflow_safe (msk, subflow, tmp) -__mptcp_close_ssk (sk,mptcp_subflow_tcp_sock (subflow), - subflow,MPTCP_CF_FASTCLOSE ); + +/* Explicitly send the fastclose reset as need */ +if (__mptcp_check_fallback (msk)) +return ; + +mptcp_for_each_subflow_safe (msk, subflow, tmp) { +struct sock *ssk =mptcp_subflow_tcp_sock (subflow); + +lock_sock (ssk); + +/* Some subflow socket states don't allow/need a reset.*/ +if ((1 << ssk->sk_state) & (TCPF_LISTEN |TCPF_CLOSE )) + goto unlock; + + subflow->send_fastclose =1 ; +tcp_send_active_reset (ssk, ssk->sk_allocation); +unlock: +release_sock (ssk); + } }static void mptcp_worker (struct work_struct *work)
Patches currently in stable-queue which might be from [email protected] are
queue-6.6/mptcp-clear-scheduled-subflows-on-retransmit.patch queue-6.6/mptcp-fix-duplicate-reset-on-fastclose.patch queue-6.6/selftests-mptcp-join-properly-kill-background-tasks.patch