Re: [PATCH net-next v4 1/2] tcp: keep the route window metric when SO_RCVBUF is set before connect

[shashank Jain]

> [Medium] tcp: unordered lockless reads of window_clamp in tcp_req_window_clamp()

Right, nothing orders the two loads against the two stores in
setsockopt(TCP_WINDOW_CLAMP) or tcp_disconnect(). The case that matters
is the one where window_clamp reads 0: the request then gets no clamp at
all. Any other stale value is a clamp the listener had just before, the
same as a SYN that arrives just before the setsockopt(). And a
setsockopt() between the SYN-ACK and the cookie ACK changes the clamp
whatever the ordering.

So in v5 tcp_req_window_clamp() falls back to the user's clamp when
window_clamp reads 0, without barriers:

u32 user_clamp = READ_ONCE(tp->window_clamp_user);

if (!user_clamp)
return dst_metric(dst, RTAX_WINDOW);
return READ_ONCE(tp->window_clamp) ? : user_clamp;

I kept window_clamp rather than the stored user value, because a listener's
window_clamp can legitimately differ from it: SO_RCVBUF lowers it, and
SO_RCVLOWAT raises it so that the window can hold rcvlowat bytes. Capping
that at the user's clamp could leave a reader waiting for data the window
does not let in. The plain store in tcp_disconnect() becomes WRITE_ONCE(),
and the changelog no longer says that READ_ONCE()/WRITE_ONCE() make this
path safe.

> [Low] The changelog says: "Without an RTAX_WINDOW metric and without
> TCP_WINDOW_CLAMP nothing changes".

Correct for MPTCP subflows. mptcp_set_rcvlowat() writes the subflow's
window_clamp without setting window_clamp_user, so tcp_connect_init() now
replaces it with the route metric, as for plain TCP, where
tcp_set_rcvlowat() only raises a clamp that is already non-zero. v5 says
this in the changelog and Cc's the MPTCP maintainers.

> Pre-existing issues:
> - [Medium] The patch adds tp->window_clamp_user and comments that
>   window_clamp "never goes above a clamp the user set with...

Agreed, the comment and the changelog claim more than the patch does.
Only tcp_set_rcvbuf() is capped. tcp_measure_rcv_mss(), tcp_rcvbuf_grow()
and SO_RCVLOWAT still set window_clamp without looking at the user's
clamp, as before this patch. v5 rewords both to cover only the SO_RCVBUF
path. Whether autotuning should respect TCP_WINDOW_CLAMP is a separate
question that this patch doesn't change. I can look at it as a follow-up
once window_clamp_user is in.

v5 will go out when net-next reopens, without the Fixes: tag as Jakub
asked.

pw-bot: cr

On Thu, Oct 22, 2026 at 2:21 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Wed, 21 Oct 2026 21:27:14 +0530 Shashank Mohan Jain wrote:
> > The problem was found by code inspection, assisted by an LLM (Claude
> > Code, Claude Opus 5.5), while reviewing the commit above. It was
> > confirmed with a reproducer in a qemu guest (two netns joined by a veth
> > pair, "ip route ... window 4096", tcpdump of the SYN and SYN-ACK, and
> > TCP_INFO of both ends, including a SYN cookie case), and with the
> > packetdrill tests added by the next patch, which fail without this
> > patch and pass with it.
>
> Sounds like a genuine net-next material. Please drop the Fixes tag
> completely, and repost after net-next reopens
>
> If someone disagrees please speak up.
>
>
> ## Form letter - net-next-closed
>
> The merge window for Linux v7.4 has begun, and the net-next
> tree is now closed for new drivers, features, code refactoring
> and optimizations. We are currently accepting bug fixes only.
>
> Please repost when net-next reopens. There is some uncertainty
> about how long this merge window will last, so please check
> https://netdev.bots.linux.dev/net-next.html
> before reposting. net-next _may_ reopen on Nov 2nd.
>
> See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
> --
> pw-bot: defer