From: Tejas Birajdar <tejasbirajdar@meta.com>
To: Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>, <netdev@vger.kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>, <bpf@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Tejas Birajdar <tejasbirajdar@meta.com>,
Sashiko <sashiko-bot@kernel.org>
Subject: [PATCH net-next v3] tcp: honor BPF_SOCK_OPS_RWND_INIT on the active connect path
Date: Thu, 30 Jul 2026 15:00:55 -0700 [thread overview]
Message-ID: <20260730220055.2946171-1-tejasbirajdar@meta.com> (raw)
BPF_SOCK_OPS_RWND_INIT lets a sockops BPF program pick the initial TCP
receive window, e.g. to advertise a larger window up front in environments
where that is known to be safe. Today it is only effective for the passive
(listener) side; on the active (connect) side the value is computed and
then silently discarded.
On the passive path tcp_openreq_init_rwin() inflates full_space when the
program returns a non-zero window, so tcp_select_initial_window() can offer
it:
else if (full_space < (u64)rcv_wnd * mss)
full_space = min_t(u64, (u64)rcv_wnd * mss, INT_MAX);
tcp_select_initial_window() only clamps the requested window *down* to the
available space, so without inflating the space first the BPF reply can
never raise the offered window above tcp_full_space(sk).
tcp_connect_init() calls tcp_rwnd_init_bpf() but never inflates full_space,
so on connect() the requested window is clamped back to tcp_full_space(sk)
(~64KB at the default rcvbuf) and the program's value is ignored.
Inflate full_space in tcp_connect_init() as well; tp->advmss is the mss the
listener path uses (both are tcp_mss_clamp(tp, dst_metric_advmss(dst))).
Read full_space after tcp_rwnd_init_bpf() so a program that also adjusts
SO_RCVBUF is still reflected. Compute the inflated value in u64 and clamp
to INT_MAX to avoid overflow (full_space is int, rcv_wnd is u32), and
apply the same overflow fix to the existing listener-side computation.
tcp_select_initial_window() itself also computes init_rcv_wnd * mss in
32-bit when clamping the offered window down to the requested value. A
large requested window (init_rcv_wnd greater than ~2.9M segments at
1460 mss) wraps this multiply and collapses the offered window to a tiny
value, so compute it in u64 as well.
Fixes: 13d3b1ebe287 ("bpf: Support for setting initial receive window")
Suggested-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Suggested-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Tejas Birajdar <tejasbirajdar@meta.com>
---
v3:
- Also compute init_rcv_wnd * mss in u64 in tcp_select_initial_window();
a large requested window otherwise overflows the 32-bit multiply and
collapses the offered window.
v2: https://lore.kernel.org/netdev/20260723214208.3655474-1-tejasbirajdar@meta.com/
- Compute the inflated full_space in u64 and clamp to INT_MAX in both the
connect and listener paths; read full_space after tcp_rwnd_init_bpf().
v1: https://lore.kernel.org/netdev/20260722170033.2763794-1-tejasbirajdar@meta.com/
Verified on the connect path with packetdrill: the offered initial window
now tracks the BPF-requested value, and a large request that previously
overflowed no longer collapses it. No new failures in the in-tree
packetdrill selftests.
net/ipv4/tcp_minisocks.c | 4 ++--
net/ipv4/tcp_output.c | 8 ++++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index ddc4b17a826b..f8c1123aba43 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -453,8 +453,8 @@ void tcp_openreq_init_rwin(struct request_sock *req,
rcv_wnd = tcp_rwnd_init_bpf((struct sock *)req);
if (rcv_wnd == 0)
rcv_wnd = dst_metric(dst, RTAX_INITRWND);
- else if (full_space < rcv_wnd * mss)
- full_space = rcv_wnd * mss;
+ else if (full_space < (u64)rcv_wnd * mss)
+ full_space = min_t(u64, (u64)rcv_wnd * mss, INT_MAX);
/* tcp_full_space because it is guaranteed to be the first packet */
tcp_select_initial_window(sk_listener, full_space,
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index d7c1444b5e30..fcaa04e65189 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -251,7 +251,7 @@ void tcp_select_initial_window(const struct sock *sk, int __space, __u32 mss,
(*rcv_wnd) = space;
if (init_rcv_wnd)
- *rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);
+ *rcv_wnd = min_t(u64, *rcv_wnd, (u64)init_rcv_wnd * mss);
*rcv_wscale = 0;
if (wscale_ok) {
@@ -4103,6 +4103,7 @@ static void tcp_connect_init(struct sock *sk)
const struct dst_entry *dst = __sk_dst_get(sk);
struct tcp_sock *tp = tcp_sk(sk);
__u8 rcv_wscale;
+ int full_space;
u16 user_mss;
u32 rcv_wnd;
@@ -4137,10 +4138,13 @@ static void tcp_connect_init(struct sock *sk)
WRITE_ONCE(tp->window_clamp, tcp_full_space(sk));
rcv_wnd = tcp_rwnd_init_bpf(sk);
+ full_space = tcp_full_space(sk);
if (rcv_wnd == 0)
rcv_wnd = dst_metric(dst, RTAX_INITRWND);
+ else if (full_space < (u64)rcv_wnd * tp->advmss)
+ full_space = min_t(u64, (u64)rcv_wnd * tp->advmss, INT_MAX);
- tcp_select_initial_window(sk, tcp_full_space(sk),
+ tcp_select_initial_window(sk, full_space,
tp->advmss - (tp->rx_opt.ts_recent_stamp ? tp->tcp_header_len - sizeof(struct tcphdr) : 0),
&tp->rcv_wnd,
&tp->window_clamp,
--
2.53.0-Meta
next reply other threads:[~2026-07-30 22:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 22:00 Tejas Birajdar [this message]
[not found] ` <20260731220124.B0C621F00AC4@smtp.kernel.org>
2026-08-06 9:15 ` [PATCH net-next v3] tcp: honor BPF_SOCK_OPS_RWND_INIT on the active connect path Paolo Abeni
2026-08-06 13:45 ` Eric Dumazet
2026-08-06 19: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=20260730220055.2946171-1-tejasbirajdar@meta.com \
--to=tejasbirajdar@meta.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sashiko-bot@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