From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01F773F9FB for ; Mon, 1 Jun 2026 00:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780274349; cv=none; b=YjdGHGoqxG+O8nEEHuKRiesUVxShG8sekMR019z08YL4FQmQo+A527uJLcWsprmUJFeWUwTYcWgcMVdcAap5FsqxGGLjREpjUM5oIaLj9max1CEbpWxsVNCPO3Hdp8tq5gzeT6Zr49Kjr1YO/4r8CRkihD/WCFkBM4Bfa6yphdw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780274349; c=relaxed/simple; bh=OAUhShPwUr9ucLakdDfQ+nHSH4mMGn/PkJXt7HbxODk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QNPKdb3gEVwGs1x/Rj7wuwCHPLdinCjLtjqzjnei8gWgp7C2nju9fkvrh62DWLE6NhT2Gl4hLEzbt63mxYEJWbWaZMt1WWKetvcORlUc9NN2k+HujgBAFO57yzi3dGr92yNWzEUUWmHRNpXqyrKLtr8vwihiFJRJPL9H4wxZBpk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NNxhKvdV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NNxhKvdV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13ADD1F00893; Mon, 1 Jun 2026 00:39:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780274347; bh=vp8+bDDY5VdToqJn3J2Et+7d7TZBbHFOxwkingLt/5M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=NNxhKvdVdDDM0qBi9oG8dBLM1Pnhq5cHBxK53lZKSL11McEaZ3SuiBrBs+kRt45oK aQ3j53G7x9fm26CKUl9Ba6VFGGlC22x128hPNgI2zBSM5bbYZyDAQY9YZkjkY9TxYs j8GutSuPGFJXpauIvmco7TkGlvWuK0bYrZwPAq4nEEB+3rp6rLZWLLlUxBhYbhIgki mBsSlrKv80eNDo9kBThmEdHmGZxMzlycLz/Aa362j1Bdejj5qfS7UsbzPvrnoBzjYO 1geFQwEYmKkq0dDlu9pPNAhQle6S2mfdF8jUTweXK39BdVkjAOCKVpyFoNZMDaPeyQ FPO9kalEVVfvA== From: Sasha Levin To: stable@vger.kernel.org Cc: Gang Yan , "Matthieu Baerts (NGI0)" , Paolo Abeni , Sasha Levin Subject: [PATCH 7.0.y] mptcp: update window_clamp on subflows when SO_RCVBUF is set Date: Sun, 31 May 2026 20:39:05 -0400 Message-ID: <20260601003905.84041-1-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <2026052819-liberty-cramp-97fe@gregkh> References: <2026052819-liberty-cramp-97fe@gregkh> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Gang Yan [ Upstream commit 3a543ae0e2092d5c2085d5f21f7a7dbafdffea3c ] Add __mptcp_subflow_set_rcvbuf() helper to write the subflow sk_rcvbuf, but also to call the recently added tcp_set_rcvbuf() helper to update window_clamp. This is needed because the window clap is updated when scaling_ratio changes, in tcp_measure_rcv_mss(). Until scaling_ratio changes, the subflow is stuck with the old window clamp which may be based on a small initial buffer. Use this new helper in both mptcp_sol_socket_sync_intval() (setsockopt path) and sync_socket_options() (new subflow creation path). Note that this patch depends on commit b025461303d8 ("tcp: update window_clamp when SO_RCVBUF is set"): it fixes the issue on TCP side, but the same fix is needed on MPTCP side as well. Fixes: a2cbb1603943 ("tcp: Update window clamping condition") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/619 Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-5-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni [ inlined missing `tcp_set_rcvbuf()` to `tcp_set_window_clamp(ssk, tcp_win_from_space(ssk, val))` ] Signed-off-by: Sasha Levin --- net/mptcp/sockopt.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c index 1cf608e7357bd..52f4accf2bba4 100644 --- a/net/mptcp/sockopt.c +++ b/net/mptcp/sockopt.c @@ -67,6 +67,12 @@ static int mptcp_get_int_option(struct mptcp_sock *msk, sockptr_t optval, return 0; } +static void __mptcp_subflow_set_rcvbuf(struct sock *ssk, int val) +{ + WRITE_ONCE(ssk->sk_rcvbuf, val); + tcp_set_window_clamp(ssk, tcp_win_from_space(ssk, val)); +} + static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, int val) { struct mptcp_subflow_context *subflow; @@ -100,7 +106,7 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in case SO_RCVBUF: case SO_RCVBUFFORCE: ssk->sk_userlocks |= SOCK_RCVBUF_LOCK; - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf); + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf); break; case SO_MARK: if (READ_ONCE(ssk->sk_mark) != sk->sk_mark) { @@ -1560,7 +1566,7 @@ static void sync_socket_options(struct mptcp_sock *msk, struct sock *ssk) mptcp_subflow_ctx(ssk)->cached_sndbuf = sk->sk_sndbuf; } if (sk->sk_userlocks & SOCK_RCVBUF_LOCK) - WRITE_ONCE(ssk->sk_rcvbuf, sk->sk_rcvbuf); + __mptcp_subflow_set_rcvbuf(ssk, sk->sk_rcvbuf); } if (sock_flag(sk, SOCK_LINGER)) { -- 2.53.0