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.
Signed-off-by: Tejas Birajdar <tejasbirajdar@meta.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260730220055.2946171-1-tejasbirajdar@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ca10634ebc