mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®