From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
To: mptcp@lists.linux.dev, stable@vger.kernel.org,
gregkh@linuxfoundation.org
Cc: Paolo Abeni <pabeni@redhat.com>,
sashal@kernel.org, Xinyang Ge <xinyang@anthropic.com>,
"Matthieu Baerts (NGI0)" <matttbe@kernel.org>,
Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH 6.18.y 2/4] mptcp: avoid unneeded actions on subflow reset
Date: Sat, 19 Sep 2026 21:39:51 +0200 [thread overview]
Message-ID: <20260919193948.1927666-8-matttbe@kernel.org> (raw)
In-Reply-To: <20260919193948.1927666-6-matttbe@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
commit 2b0f561f21b27c40c91ea4975268a06092bd7e9c upstream.
Once in a blue moon, the mptcp receive path can recursively call
mptcp_data_ready() via state change under unlucky error conditions, and
then try to hold the data lock again.
Break the recursion loop explicitly checking for the exceptional
condition.
Add a new flag instead of using an existing one like 'closing', to exit
early in subflow_state_change(), and explicitly flush the RX queue at
reset time.
This avoids unneeded processing to check for available data -- calling
get_mapping_status() and more on a dying subflow -- but also in error
reporting and worker scheduling.
Note that we must consume the currently peeked skb before invoking
mptcp_dss_corruption to avoid consuming it again after the eventual
reset has freed it.
Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption")
Cc: stable@vger.kernel.org
Reported-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 4 ++--
net/mptcp/protocol.h | 3 ++-
net/mptcp/subflow.c | 11 +++++++++++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index a9d8f63d3b2a..dee5fd3787b5 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -727,12 +727,12 @@ static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk,
mptcp_dss_corruption(msk, ssk);
}
} else {
+ sk_eat_skb(ssk, skb);
+
if (unlikely(!fin)) {
DEBUG_NET_WARN_ON_ONCE(1);
mptcp_dss_corruption(msk, ssk);
}
-
- sk_eat_skb(ssk, skb);
}
WRITE_ONCE(tp->copied_seq, seq);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 68f7c67d5f49..dc8920a6a90c 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -545,7 +545,8 @@ struct mptcp_subflow_context {
is_mptfo : 1, /* subflow is doing TFO */
close_event_done : 1, /* has done the post-closed part */
mpc_drop : 1, /* the MPC option has been dropped in a rtx */
- __unused : 9;
+ resetting : 1, /* subflow is resetting */
+ __unused : 8;
bool data_avail;
bool scheduled;
bool pm_listener; /* a listener managed by the kernel PM? */
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 96794baac3e1..1932fcf9f925 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -441,6 +441,10 @@ void mptcp_subflow_reset(struct sock *ssk)
/* must hold: tcp_done() could drop last reference on parent */
sock_hold(sk);
+ subflow->resetting = 1;
+
+ /* No need to delay the actual close for to-be discarded data. */
+ __skb_queue_purge(&ssk->sk_receive_queue);
mptcp_send_active_reset_reason(ssk);
tcp_done(ssk);
if (!test_and_set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &mptcp_sk(sk)->flags))
@@ -1864,6 +1868,13 @@ static void subflow_state_change(struct sock *sk)
__subflow_state_change(sk);
+ /* Rx queue processing is unneeded, error reporting will take place at
+ * __mptcp_close_ssk() time and subflow reset can't happen in case of
+ * fallback: subflow_sched_work_if_closed() would be a no-op.
+ */
+ if (subflow->resetting)
+ return;
+
/* as recvmsg() does not acquire the subflow socket for ssk selection
* a fin packet carrying a DSS can be unnoticed if we don't trigger
* the data available machinery here.
--
2.55.0
next prev parent reply other threads:[~2026-09-19 19:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 19:39 [PATCH 6.18.y 0/4] mptcp: fix recent failed backports (20260919) Matthieu Baerts (NGI0)
2026-09-19 19:39 ` [PATCH 6.18.y 1/4] mptcp: move the stale logic out of retrans scheduler Matthieu Baerts (NGI0)
2026-09-20 7:36 ` Patch "mptcp: move the stale logic out of retrans scheduler" has been added to the 6.18-stable tree gregkh
2026-09-19 19:39 ` Matthieu Baerts (NGI0) [this message]
2026-09-20 7:36 ` Patch "mptcp: avoid unneeded actions on subflow reset" " gregkh
2026-09-19 19:39 ` [PATCH 6.18.y 3/4] mptcp: close race between scheduler and state change Matthieu Baerts (NGI0)
2026-09-20 7:36 ` Patch "mptcp: close race between scheduler and state change" has been added to the 6.18-stable tree gregkh
2026-09-19 19:39 ` [PATCH 6.18.y 4/4] mptcp: fix bad accounting in __mptcp_subflow_push_pending() Matthieu Baerts (NGI0)
2026-09-20 7:36 ` Patch "mptcp: fix bad accounting in __mptcp_subflow_push_pending()" has been added to the 6.18-stable tree gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260919193948.1927666-8-matttbe@kernel.org \
--to=matttbe@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xinyang@anthropic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.