Re: [PATCH RFC -next 3/5] mptcp: sync memcg budget and drop backlog page compensation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mptcp: memcg accounting bypass when propagating SO_SNDBUF to subflows
--

commit 81a89371b8c44bb27224e5c7531703509f0431a0
Author: Cai Xinchen <caixinchen1@huawei.com>

mptcp: sync memcg budget and drop backlog page compensation

This commit syncs the memcg budget tracker at MPTCP budget writes and
refunds budgets when subflows move to the msk's memcg. By charging budgets
upfront, it removes the per-page compensation mechanism for unaccounted
backlogs to prevent double-charging.

[ ... ]

> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index fcf6feb2a9eb5..05d9dafa8c071 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -70,6 +70,7 @@ static int mptcp_get_int_option(struct mptcp_sock *msk, sockptr_t optval,
>  static void __mptcp_subflow_set_rcvbuf(struct sock *ssk, int val)
>  {
>  	WRITE_ONCE(ssk->sk_rcvbuf, val);
> +	sk_memcg_budget_sync(ssk, gfp_memcg_charge());
>  	tcp_set_rcvbuf(ssk, val);
>  }

[Severity: High]
This patch introduces upfront memcg charging and correctly syncs the budget
for SO_RCVBUF updates via __mptcp_subflow_set_rcvbuf(), but is it also
necessary to sync the budget for SO_SNDBUF updates?

When SO_SNDBUF is propagated to subflows, the socket buffer limits are
updated but the memcg budget is not synced. For example, in
mptcp_sol_socket_sync_intval():

	case SO_SNDBUF:
	case SO_SNDBUFFORCE:
		ssk->sk_userlocks |= SOCK_SNDBUF_LOCK;
		WRITE_ONCE(ssk->sk_sndbuf, sk->sk_sndbuf);
		mptcp_subflow_ctx(ssk)->cached_sndbuf = sk->sk_sndbuf;
		break;

And similarly in sync_socket_options() when newly joined subflows inherit
the options:

	if (sk->sk_userlocks & SOCK_SNDBUF_LOCK) {
		WRITE_ONCE(ssk->sk_sndbuf, sk->sk_sndbuf);
		mptcp_subflow_ctx(ssk)->cached_sndbuf = sk->sk_sndbuf;
	}

Could this bypass memcg accounting for MPTCP subflows, allowing TCP socket
buffers to grow up to the new limits without the cgroup being charged?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924080219.1036588-1-caixinchen1@huawei.com?part=3