From: netdev-bot+sashiko@kernel.org
To: matttbe@kernel.org
Cc: martineau@kernel.org, geliang@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, netdev@vger.kernel.org, mptcp@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net v2 01/15] mptcp: do not reschedule the RTX timer for fallback sockets
Date: Wed, 09 Sep 2026 14:49:32 +0000 [thread overview]
Message-ID: <178896537258.219967.9085177988970978054@kernel.org> (raw)
In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 · Low: 0
- [Medium] Incomplete gate: mptcp_connect() (net/mptcp/protocol.c:4149)
unconditionally does set_bit(MPTCP_RTX_ENABLED, &msk->flags) before…
--
mptcp: do not reschedule the RTX timer for fallback sockets
This adds a new MPTCP_RTX_ENABLED flag bit so that mptcp_reset_rtx_timer()
only arms the MPTCP retransmission timer while the msk has not fallen back
to plain TCP and is not closed. The bit is set in mptcp_connect() and
mptcp_listen(), and cleared on fallback and on the transition to TCP_CLOSE.
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index e1f08f71cdb1..be59651e708e 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -95,6 +95,7 @@ bool __mptcp_try_fallback(struct mptcp_sock *msk, int fb_mib)
>
> msk->allow_subflows = false;
> set_bit(MPTCP_FALLBACK_DONE, &msk->flags);
> + clear_bit(MPTCP_RTX_ENABLED, &msk->flags);
> __MPTCP_INC_STATS(net, fb_mib);
> spin_unlock_bh(&msk->fallback_lock);
> return true;
> @@ -1084,13 +1085,14 @@ static bool mptcp_rtx_timer_pending(struct sock *sk)
>
> static void mptcp_reset_rtx_timer(struct sock *sk)
> {
> + struct mptcp_sock *msk = mptcp_sk(sk);
> unsigned long tout;
>
> - /* prevent rescheduling on close */
> - if (unlikely(inet_sk_state_load(sk) == TCP_CLOSE))
> + /* Prevent rescheduling on close and in case of fallback. */
> + if (!test_bit(MPTCP_RTX_ENABLED, &msk->flags))
> return;
>
> - tout = mptcp_sk(sk)->timer_ival;
> + tout = msk->timer_ival;
> sk_reset_timer(sk, &sk->mptcp_retransmit_timer, jiffies + tout);
> }
>
[ ... ]
> @@ -4141,6 +4146,7 @@ static int mptcp_connect(struct sock *sk, struct sockaddr_unsized *uaddr,
> if (IS_ERR(ssk))
> return PTR_ERR(ssk);
>
> + set_bit(MPTCP_RTX_ENABLED, &msk->flags);
> mptcp_set_state(sk, TCP_SYN_SENT);
> subflow = mptcp_subflow_ctx(ssk);
[Severity: Medium]
Can this set_bit() re-enable the RTX timer on a msk that is already in
fallback? It runs unconditionally, before any of the fallback checks below
it, and the fallback state is sticky across a failed connect().
Sequence that seems reachable from userspace on its own fd:
1) First connect(): mptcp_active_should_disable() is true (or
mptcp_token_new_connect() fails), so mptcp_connect() calls
mptcp_early_fallback() -> __mptcp_try_fallback(), which sets
MPTCP_FALLBACK_DONE, clears MPTCP_RTX_ENABLED and leaves
subflow->request_mptcp == 0.
2) ssk->sk_prot->connect() fails immediately (for instance -EAFNOSUPPORT on
a bad sin_family, or -ENETUNREACH from the route lookup), so
mptcp_connect() takes:
if (unlikely(err)) {
/* avoid leaving a dangling token in an unconnected socket */
mptcp_token_destroy(msk);
mptcp_set_state(sk, TCP_CLOSE);
return err;
}
MPTCP_RTX_ENABLED is cleared again by the TCP_CLOSE transition, but
MPTCP_FALLBACK_DONE stays set.
3) __inet_stream_connect() returns the error directly:
err = sk->sk_prot->connect(sk, uaddr, addr_len);
if (err < 0)
goto out;
so sk->sk_prot->disconnect() (mptcp_disconnect(), which does
WRITE_ONCE(msk->flags, 0)) is never called, and the socket stays
SS_UNCONNECTED with sk_state == TCP_CLOSE.
4) Userspace calls connect() again. mptcp_connect() sets
MPTCP_RTX_ENABLED unconditionally, and since request_mptcp is already 0
the fallback branches are skipped. Even if mptcp_early_fallback() were
reached, __mptcp_try_fallback() returns early at:
if (__mptcp_check_fallback(msk))
return true;
before the new clear_bit(MPTCP_RTX_ENABLED, ...).
The result is a live fallback msk with MPTCP_RTX_ENABLED set, so
mptcp_reset_rtx_timer() passes the new gate and the send paths
(__mptcp_push_pending() and friends) arm the MPTCP RTX timer just as they
did before the patch:
if (!mptcp_rtx_timer_pending(sk))
mptcp_reset_rtx_timer(sk);
Would gating the set_bit() on !__mptcp_check_fallback(msk), or moving it
below the early-fallback checks, close this case and also make the new
comment "Prevent rescheduling on close and in case of fallback" hold for a
msk whose fallback predates the current connect()?
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6%40kernel.org
next prev parent reply other threads:[~2026-09-09 14:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 14:07 [PATCH net v2 00/15] mptcp: misc fixes for v7.3-rc1 Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 01/15] mptcp: do not reschedule the RTX timer for fallback sockets Matthieu Baerts (NGI0)
2026-09-09 14:49 ` netdev-bot+sashiko [this message]
2026-09-09 15:32 ` Paolo Abeni
2026-09-08 14:07 ` [PATCH net v2 02/15] mptcp: subflow: no need to copy thmac during ulp_clone Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 03/15] mptcp: syncookies: remember the request backup flag Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 04/15] mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 Matthieu Baerts (NGI0)
2026-09-09 14:49 ` netdev-bot+sashiko
2026-09-09 17:57 ` Matthieu Baerts
2026-09-08 14:07 ` [PATCH net v2 05/15] mptcp: options: handle MPC data + csum reqd + no csum Matthieu Baerts (NGI0)
2026-09-09 14:49 ` netdev-bot+sashiko
2026-09-09 18:03 ` Matthieu Baerts
2026-09-08 14:07 ` [PATCH net v2 06/15] mptcp: prevent race between disconnect() and rtx Matthieu Baerts (NGI0)
2026-09-09 14:49 ` netdev-bot+sashiko
2026-09-09 15:54 ` Paolo Abeni
2026-09-09 18:05 ` Matthieu Baerts
2026-09-08 14:07 ` [PATCH net v2 07/15] selftests: mptcp: fix an UAF in mptcp_connect.c Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 08/15] mptcp: pm: userspace: fix address ID overflow Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 09/15] mptcp: pm: reset retrans_time when ADD_ADDR entry is reused Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 10/15] mptcp: remove unneeded READ_ONCE() annotation Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 11/15] selftests: mptcp: lib: dump nstat for the right test Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 12/15] selftests: mptcp: lib: get counters " Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 13/15] mptcp: options: fix uninit-value in mptcp_write_data_fin Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 14/15] mptcp: being below memory limit is a likely() condition Matthieu Baerts (NGI0)
2026-09-08 14:07 ` [PATCH net v2 15/15] mptcp: avoid pruning for OoW data Matthieu Baerts (NGI0)
2026-09-09 14:49 ` netdev-bot+sashiko
2026-09-09 15:50 ` Paolo Abeni
2026-09-09 18:07 ` Matthieu Baerts
2026-09-09 18:09 ` [PATCH net v2 00/15] mptcp: misc fixes for v7.3-rc1 Matthieu Baerts
2026-09-09 20:40 ` patchwork-bot+netdevbpf
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=178896537258.219967.9085177988970978054@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®