All of lore.kernel.org
 help / color / mirror / Atom feed
From: gang.yan@linux.dev
To: "Yingjie Wang" <x-professor@outlook.com>, netdev@vger.kernel.org
Cc: mptcp@lists.linux.dev, linux-kernel@vger.kernel.org,
	edumazet@kernel.org, ncardwell@google.com, kuniyu@google.com,
	davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, matttbe@kernel.org, martineau@kernel.org,
	geliang@kernel.org, ycheng@google.com, weiwan@google.com,
	stable@vger.kernel.org
Subject: Re: [PATCH net 2/2] mptcp: avoid wrapping blackhole timeout
Date: Thu, 12 Nov 2026 07:15:45 +0000	[thread overview]
Message-ID: <a5e30ae63ebb4a71327031211b50b33230e50004@linux.dev> (raw)
In-Reply-To: <738e11db58137c0082b53fb1662ab0b70763f51a.1794325665.git.x-professor@outlook.com>

> 
> mptcp_active_should_disable() calculates the active-disable interval as
> multiplier * blackhole_timeout * HZ. Since all operands are 32-bit, a
> large blackhole_timeout can wrap the delay even on 64-bit kernels and
> make active MPTCP available again while the blackhole is still present.
> 
> For example, with HZ=1000, a timeout of 6912213 seconds and the maximum
> multiplier of 64 should produce 442381632000 jiffies, but the current
> calculation truncates it to 512 jiffies.
> 
> This issue was found using a static analysis tool. A loopback reproducer
> induced 12 MPTCP blackholes and waited 1.2 seconds before opening another
> connection. The unpatched kernel retried MP_CAPABLE, while the patched
> kernel kept MPTCP disabled and used TCP fallback directly. The reproducer
> required neither kernel modifications nor fault injection.
> 
> Compute the interval in u64 and cap it at MAX_JIFFY_OFFSET before adding
> it to the saved timestamp. This preserves the existing exponential
> backoff for representable intervals and prevents large values from
> wrapping into short timeouts.
> 
> Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <x-professor@outlook.com>
> ---
>  net/mptcp/ctrl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
> index 63c5747f0f63..5224cfb3ed1f 100644
> --- a/net/mptcp/ctrl.c
> +++ b/net/mptcp/ctrl.c
> @@ -487,6 +487,7 @@ bool mptcp_active_should_disable(struct sock *ssk)
>  unsigned long timeout;
>  int disable_times;
>  int multiplier;
> + u64 delay;
>  
>  pernet = mptcp_get_pernet(net);
>  blackhole_timeout = READ_ONCE(pernet->blackhole_timeout);
> @@ -503,10 +504,11 @@ bool mptcp_active_should_disable(struct sock *ssk)
>  
>  /* Limit timeout to max: 2^6 * initial timeout */
>  multiplier = 1 << min(disable_times - 1, 6);
> + delay = (u64)multiplier * blackhole_timeout * HZ;
>  

Hi Yingjie,

Thanks for the patch. Basically LGTM, 


Just two small questions:

>  /* Paired with the WRITE_ONCE() in mptcp_active_disable(). */
>  timeout = READ_ONCE(pernet->active_disable_stamp) +
> - multiplier * blackhole_timeout * HZ;
> + min(delay, MAX_JIFFY_OFFSET);

1. AFAICS, on 64bit machine, the largest possible delay is 64 * INT_MAX * HZ, far
less than MAX_JIFFY_OFFSET ((LONG_MAX >> 1) - 1 = 2^62 - 2). So is the min() intended for the
32-bit machine? 

2. If so, should the comment be updated? Because there is a second timeout on 32-bit machine.


Thanks
Gang

Reviewed-by: Gang Yan <yangang@kylinos.cn>

>  
>  return time_before(jiffies, timeout);
>  }
> -- 
> 2.43.0
>

  reply	other threads:[~2026-11-12  7:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 15:47 [PATCH net 0/2] tcp/mptcp: prevent blackhole timeout arithmetic wraparound Yingjie Wang
2026-11-10 15:47 ` [PATCH net 1/2] tcp: avoid wrapping Fast Open blackhole timeout Yingjie Wang
2026-11-12  6:15   ` Kuniyuki Iwashima
2026-11-10 15:48 ` [PATCH net 2/2] mptcp: avoid wrapping " Yingjie Wang
2026-11-12  7:15   ` gang.yan [this message]
2026-11-10 17:42 ` [PATCH net 0/2] tcp/mptcp: prevent blackhole timeout arithmetic wraparound MPTCP CI

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=a5e30ae63ebb4a71327031211b50b33230e50004@linux.dev \
    --to=gang.yan@linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=geliang@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=weiwan@google.com \
    --cc=x-professor@outlook.com \
    --cc=ycheng@google.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.