[PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[Shashank Mohan Jain]

Since commit b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is
set") SO_RCVBUF sets tp->window_clamp from the new buffer size in every
socket state. For a socket without a connection this has a side
effect. tcp_connect_init() and tcp_openreq_init_rwin() use the window
metric of the route (RTAX_WINDOW, "ip route ... window N") only if
window_clamp is zero. The clamp left behind by SO_RCVBUF makes the
metric ineffective for that socket, or for the connections accepted
on a listener.

Example: two network namespaces connected by a veth pair, "window
4096" on the route to the peer on both sides, SO_RCVBUF set to 1 MiB
before connect():

  v7.3-rc6:                    SYN win 65535, wscale 5
                               TCP_WINDOW_CLAMP 1047128
  with that commit reverted:   SYN win 2920, no window scaling
                               TCP_WINDOW_CLAMP 4096

With SO_RCVBUF set on the listener the SYN-ACK and the clamp of the
accepted socket differ in the same way.

The update is not needed in these states. When the connection is set
up with SOCK_RCVBUF_LOCK set, both functions limit a zero or too
large clamp to tcp_full_space(), which is the value tcp_set_rcvbuf()
computes. Skip the update for sockets in TCP_CLOSE and TCP_LISTEN.

Tested in qemu with the setup above. With the route metric, the SYN
and SYN-ACK windows and TCP_WINDOW_CLAMP are the same as with the
commit above reverted. Without the metric they are the same as before
this change, with and without SO_RCVBUF on either side.

Fixes: b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
---
Prepared with Claude Code (Anthropic), model Claude Opus 5.5
(claude-opus-5-5).

 net/ipv4/tcp.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 87ef6d5cbf..9b6f214411 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1856,6 +1856,14 @@ int tcp_set_rcvlowat(struct sock *sk, int val)
 
 void tcp_set_rcvbuf(struct sock *sk, int val)
 {
+	/* Without a connection there is no clamp to update: it is chosen
+	 * from the route's window metric and the buffer size when the
+	 * connection is set up, see tcp_connect_init() and
+	 * tcp_openreq_init_rwin().
+	 */
+	if ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))
+		return;
+
 	tcp_set_window_clamp(sk, tcp_win_from_space(sk, val));
 }
 

base-commit: a5ebb76233b79db01e82e061173cb73c6d2b5c6b
-- 
2.43.0

Re: [PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[shashank Jain]

The issue was found by manual code inspection assisted by an LLM
(Claude Code, Claude Opus), while reviewing the networking changes that
set window_clamp on unconnected sockets, and then confirmed with a
reproducer before posting. The patch carries an "Assisted-by: LLM" tag
for that reason.

Reproducer: mainline a5ebb76233b7 built for x86_64 and booted in qemu,
two network namespaces joined by a veth pair, with
"ip route replace 10.0.0.0/24 dev <veth> window 4096" on both sides. A
small program sets SO_RCVBUF before connect()/listen() and reads
TCP_WINDOW_CLAMP and tcp_info, and the SYN/SYN-ACK is captured with
tcpdump.

Without SO_RCVBUF the route's window metric is applied
(TCP_WINDOW_CLAMP=4096, rcv_wscale=0, SYN "win 2920, wscale 0"). With
SO_RCVBUF set before connect, mainline reports TCP_WINDOW_CLAMP ~1 MB
and rcv_wscale=5, i.e. the route metric is ignored. Reverting
b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set") or
applying this patch restores TCP_WINDOW_CLAMP=4096 and the scaled-down
SYN window; with no route metric configured, mainline, the revert and
the patch behave identically in all four combinations.

Thanks,
Shashank

On Sun, Oct 11, 2026 at 10:54 AM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Re: [PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[Eric Dumazet]

Le dim. 11 oct. 2026 à 07:26, shashank Jain <jain.sm@gmail.com> a écrit :
>
> The issue was found by manual code inspection assisted by an LLM
> (Claude Code, Claude Opus), while reviewing the networking changes that
> set window_clamp on unconnected sockets, and then confirmed with a
> reproducer before posting. The patch carries an "Assisted-by: LLM" tag
> for that reason.
>
> Reproducer: mainline a5ebb76233b7 built for x86_64 and booted in qemu,
> two network namespaces joined by a veth pair, with
> "ip route replace 10.0.0.0/24 dev <veth> window 4096" on both sides. A
> small program sets SO_RCVBUF before connect()/listen() and reads
> TCP_WINDOW_CLAMP and tcp_info, and the SYN/SYN-ACK is captured with
> tcpdump.
>
> Without SO_RCVBUF the route's window metric is applied
> (TCP_WINDOW_CLAMP=4096, rcv_wscale=0, SYN "win 2920, wscale 0"). With
> SO_RCVBUF set before connect, mainline reports TCP_WINDOW_CLAMP ~1 MB
> and rcv_wscale=5, i.e. the route metric is ignored. Reverting
> b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set") or
> applying this patch restores TCP_WINDOW_CLAMP=4096 and the scaled-down
> SYN window; with no route metric configured, mainline, the revert and
> the patch behave identically in all four combinations.
>
> Thanks,
> Shashank

Note that we ask to not top post on netdev@ mailing list.

A few remarks on the changelog:

1) "TCP_WINDOW_CLAMP 4096" only holds until the first data segment.
Since a2cbb1603943 ("tcp: Update window clamping condition"),
tcp_measure_rcv_mss() overwrites window_clamp from sk_rcvbuf as soon
as scaling_ratio changes, with or without your patch. What the patch
really restores is the SYN/SYN-ACK window and the window scale.
Please say so.

2) "no window scaling" is not accurate: we still send the option,
with a shift of 0.

3) This also fixes TCP_WINDOW_CLAMP being overwritten by a later
SO_RCVBUF on a not yet connected socket or a listener. This is
probably more common than the route metric and worth mentioning.

A packetdrill test covering the SYN window and wscale would be nice.

It seems to be a net-next candidate, since WINDOW_CLAMP is not well
documented / defined / implemented / tested.

pw-bot: cr

Thanks.


>
> On Sun, Oct 11, 2026 at 10:54 AM <netdev-bot+sinfo@kernel.org> wrote:
> >
> > Hi!
> >
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> >
> >  - How the issue was discovered, e.g. hit in production, hit during
> >    development, syzbot report, manual code inspection, LLM or static
> >    analysis tool scan.
> >
> > Please do not repost the series just to address the above. Instead,
> > reply to this email with the missing information, so that reviewers
> > can take it into account. If the series needs another revision for
> > other reasons, please include the information in the commit messages
> > then.
> >
> > The evaluation is done by an LLM so it may be wrong, if you think
> > that is the case please reply and explain.

Re: [PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[Shashank Mohan Jain]

On Sun, Oct 11, 2026, Eric Dumazet <edumazet@kernel.org> wrote:
> Note that we ask to not top post on netdev@ mailing list.

Understood, replying inline from here on.

> 1) "TCP_WINDOW_CLAMP 4096" only holds until the first data segment.
> ... What the patch really restores is the SYN/SYN-ACK window and the
> window scale. Please say so.

Agreed, presenting the clamp as persistent was wrong. v2 says the patch
restores the window and window scale advertised in the SYN / SYN-ACK,
and notes that since a2cbb1603943 ("tcp: Update window clamping
condition") tcp_measure_rcv_mss() recomputes window_clamp from sk_rcvbuf
once the scaling ratio changes, independent of this change.

> 2) "no window scaling" is not accurate: we still send the option,
> with a shift of 0.

Right; changed to "wscale 0 (the window scale option is still sent,
with a shift of 0)".

> 3) This also fixes TCP_WINDOW_CLAMP being overwritten by a later
> SO_RCVBUF on a not yet connected socket or a listener. ... worth
> mentioning.

Done - v2 leads with the SO_RCVBUF-before-connect / listener case as the
common one, with the route metric as a second effect.

> A packetdrill test covering the SYN window and wscale would be nice.

I'll add a packetdrill test for the SYN window and wscale, with and
without SO_RCVBUF set before connect, in v2.

> It seems to be a net-next candidate ...

Will repost as [PATCH net-next].

Reposted as v2:
  https://lore.kernel.org/all/20261011111606.14753-1-jain.sm@gmail.com/

Thanks for the review.
Shashank

Re: [PATCH net] tcp: keep the route window metric when SO_RCVBUF is set before connect

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 1 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] The new check in tcp_set_rcvbuf() (net/ipv4/tcp.c:1864) uses
  sk_state to decide whether the window clamp has been chosen yet.
- [Medium] The connect error path in tcp_v4_connect() and
  tcp_v6_connect() puts the socket back in TCP_CLOSE but does not clear…

--

tcp: keep the route window metric when SO_RCVBUF is set before connect

This patch makes tcp_set_rcvbuf() skip the window_clamp update for
sockets in TCP_CLOSE and TCP_LISTEN. tcp_connect_init() and
tcp_openreq_init_rwin() only read the route's RTAX_WINDOW metric when
window_clamp is zero, so skipping the update keeps that metric in effect.

> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 87ef6d5cbfeba..9b6f2144119d1 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1856,6 +1856,14 @@ int tcp_set_rcvlowat(struct sock *sk, int val)
>  
>  void tcp_set_rcvbuf(struct sock *sk, int val)
>  {
> +	/* Without a connection there is no clamp to update: it is chosen
> +	 * from the route's window metric and the buffer size when the
> +	 * connection is set up, see tcp_connect_init() and
> +	 * tcp_openreq_init_rwin().
> +	 */
> +	if ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN))
> +		return;

[Severity: High]
Is sk_state a reliable way to tell whether tcp_connect_init() has run
yet? A socket can already be in TCP_SYN_SENT before the clamp is chosen.

net/ipv4/tcp_ipv4.c:tcp_v4_connect() {
    ...
	tcp_set_state(sk, TCP_SYN_SENT);
    ...
	if (tcp_fastopen_defer_connect(sk, &err))
		return err;
    ...
	err = tcp_connect(sk);
    ...
}

tcp_v6_connect() follows the same order. If SO_RCVBUF is set in that
window, tcp_set_rcvbuf() still writes a non-zero clamp. tcp_connect_init()
then skips the metric:

	if (!tp->window_clamp)
		WRITE_ONCE(tp->window_clamp, dst_metric(dst, RTAX_WINDOW));

There seem to be two ways to reach this.

The first is deferred Fast Open. With TCP_FASTOPEN_CONNECT and a cached
cookie, connect() returns to userspace with DEFER_CONNECT set and the
socket in SYN_SENT. A setsockopt(SO_RCVBUF) at that point goes through
sk_setsockopt()->__sock_set_rcvbuf()->tcp_set_rcvbuf() and sets the
clamp. The first write() then runs
tcp_sendmsg_fastopen()->tcp_connect()->tcp_connect_init(), and the
metric is ignored.

The second is BPF sockops. tcp_connect() runs the callback before
tcp_connect_init():

	tcp_call_bpf(sk, BPF_SOCK_OPS_TCP_CONNECT_CB, 0, NULL);
	...
	tcp_connect_init(sk);

sol_socket_sockopt() in net/core/filter.c allows SO_RCVBUF. The in-tree
samples samples/bpf/tcp_bufs_kern.c, tcp_clamp_kern.c and tcp_iw_kern.c
all set SO_RCVBUF from BPF_SOCK_OPS_TCP_CONNECT_CB.

Before b025461303d8 neither path wrote window_clamp, so the "ip route
... window N" metric was honoured. With this patch both paths still
lose it.

Should SYN_SENT before tcp_connect_init() also be covered, so the code
matches what the new comment describes?

[Severity: Medium]
Can the TCP_CLOSE early return keep a stale clamp left by a failed
connect attempt?

tcp_connect() calls tcp_connect_init(), which sets window_clamp. It can
still fail after that:

	tcp_connect_init(sk);
	...
	buff = tcp_stream_alloc_skb(sk, sk->sk_allocation, true);
	if (unlikely(!buff))
		return -ENOBUFS;

The failure label in tcp_v4_connect() puts the socket back in TCP_CLOSE.
So does late_failure in tcp_v6_connect(). Neither one resets
tp->window_clamp.

__inet_stream_connect() returns the error without calling ->disconnect,
so the reset in tcp_disconnect() never runs. The socket stays
SS_UNCONNECTED, and connect() can be called again.

Suppose SO_RCVBUF is raised between the two attempts. The new check
returns early and keeps the old, smaller clamp. Before this patch the
clamp would have been replaced with tcp_win_from_space() of the new
buffer size.

On the retry, tcp_connect_init() keeps the stale value. Because it is
non-zero, the metric is skipped. Because it is smaller than
tcp_full_space(), the SOCK_RCVBUF_LOCK branch leaves it alone:

	if (sk->sk_userlocks & SOCK_RCVBUF_LOCK &&
	    (tp->window_clamp > tcp_full_space(sk) || tp->window_clamp == 0))
		WRITE_ONCE(tp->window_clamp, tcp_full_space(sk));

tcp_select_initial_window() then limits rcv_wnd and rcv_wscale by the
old clamp. That limit stays for the whole connection.

Triggering this requires the SYN skb allocation to fail, for example
under memory pressure or with a restrictive sk_allocation, and then a
retry on the same socket. The behaviour matches what existed before
b025461303d8. Compared with the parent commit, though, this looks like
a regression for the retry case.

>  	tcp_set_window_clamp(sk, tcp_win_from_space(sk, val));
>  }

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261011052006.60585-1-jain.sm%40gmail.com