From: Kuniyuki Iwashima <kuniyu@google.com>
To: Yingjie Wang <x-professor@outlook.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"mptcp@lists.linux.dev" <mptcp@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"edumazet@kernel.org" <edumazet@kernel.org>,
"ncardwell@google.com" <ncardwell@google.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"horms@kernel.org" <horms@kernel.org>,
"matttbe@kernel.org" <matttbe@kernel.org>,
"martineau@kernel.org" <martineau@kernel.org>,
"geliang@kernel.org" <geliang@kernel.org>,
"ycheng@google.com" <ycheng@google.com>,
"weiwan@google.com" <weiwan@google.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH net 1/2] tcp: avoid wrapping Fast Open blackhole timeout
Date: Thu, 12 Nov 2026 06:15:12 +0000 [thread overview]
Message-ID: <avVX-3s3AYwtxQe7@google.com> (raw)
In-Reply-To: <340d9f1f96e235642e8b47b5e7c836a18de8dd56.1794325665.git.x-professor@outlook.com>
On Tue, 10 Nov 2026 15:47:58 +0000, Yingjie Wang wrote:
> tcp_fastopen_active_should_disable() calculates the active-disable
> interval as multiplier * tfo_bh_timeout * HZ. Since all operands are
> 32-bit, a large tcp_fastopen_blackhole_timeout_sec can wrap the delay
> even on 64-bit kernels and re-enable active Fast Open too soon.
>
> For example, with HZ=1000, a timeout of 6912213 seconds and the maximum
No one wants to configure 80 days blackhole timeout.
Please apply a sane limit in proc_tfo_blackhole_detect_timeout().
---
pw-bot: cr
> 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 Fast Open blackholes and waited 1.2 seconds before opening
> another connection. The unpatched kernel retried active Fast Open, while
> the patched kernel kept Fast Open disabled and used a regular TCP
> handshake. 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: cf1ef3f0719b ("net/tcp_fastopen: Disable active side TFO in certain scenarios")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yingjie Wang <x-professor@outlook.com>
> ---
> net/ipv4/tcp_fastopen.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> index 7f7eb3cc1c04..aeefd605414f 100644
> --- a/net/ipv4/tcp_fastopen.c
> +++ b/net/ipv4/tcp_fastopen.c
> @@ -613,6 +613,7 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
> unsigned long timeout;
> int tfo_da_times;
> int multiplier;
> + u64 delay;
>
> if (!tfo_bh_timeout)
> return false;
> @@ -626,10 +627,11 @@ bool tcp_fastopen_active_should_disable(struct sock *sk)
>
> /* Limit timeout to max: 2^6 * initial timeout */
> multiplier = 1 << min(tfo_da_times - 1, 6);
> + delay = (u64)multiplier * tfo_bh_timeout * HZ;
>
> /* Paired with the WRITE_ONCE() in tcp_fastopen_active_disable(). */
> timeout = READ_ONCE(sock_net(sk)->ipv4.tfo_active_disable_stamp) +
> - multiplier * tfo_bh_timeout * HZ;
> + min(delay, MAX_JIFFY_OFFSET);
> if (time_before(jiffies, timeout))
> return true;
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-11-12 6: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 [this message]
2026-11-10 15:48 ` [PATCH net 2/2] mptcp: avoid wrapping " Yingjie Wang
2026-11-12 7:15 ` gang.yan
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=avVX-3s3AYwtxQe7@google.com \
--to=kuniyu@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--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=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.