Re: [PATCH mptcp-next v3 1/4] mptcp: sched: avoid truncating the pacing rate in the scheduler

[email protected]
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The weighted average pacing rate computation silently overflows `u64` on high-speed networks with large send buffers, artificially clamping the calculated rate.
--

--- Patch [1]: [PATCH mptcp-next v3 1/4] mptcp: sched: avoid truncating the pacing rate in the scheduler ---
commit b2e45abf072b6d7db21560b1c0ae59fd43742be5
Author: Shardul Bankar <[email protected]>

mptcp: sched: avoid truncating the pacing rate in the scheduler

This commit addresses truncation and overflow issues in the MPTCP
scheduler's pacing rate computations. It widens the pace variable to
unsigned long and casts the pacing-rate average product to u64 to
prevent 32-bit integer overflow. It also uses div64_u64 for the linger
time calculation.

> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index c2762d74f29d7..46a49ec75e784 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c

[ ... ]

> @@ -1691,7 +1692,7 @@ struct sock *mptcp_subflow_get_send(struct mptcp_sock *msk)
>  
>  	subflow = mptcp_subflow_ctx(ssk);
>  	subflow->avg_pacing_rate = div_u64((u64)subflow->avg_pacing_rate * wmem +
> -					   READ_ONCE(ssk->sk_pacing_rate) * burst,
> +					   (u64)READ_ONCE(ssk->sk_pacing_rate) * burst,
>  					   burst + wmem);

[Severity: High]
This is a pre-existing issue, but is it possible for the weighted average
pacing rate computation to still silently overflow a u64 on high-speed
networks with large send buffers?

If mptcp_subflow_get_send() computes the moving average of the pacing rate
for a connection with a large send buffer (e.g., 2 GB) combined with a high
or unlimited pacing rate, the numerator ((u64)subflow->avg_pacing_rate *
wmem + (u64)READ_ONCE(ssk->sk_pacing_rate) * burst) can exceed 64 bits
before division.

This could artificially clamp the calculated rate, drastically reducing it.
For example, an unlimited pacing rate (~0UL) with a 2 GB send buffer might
be incorrectly throttled to ~73 Gbps, and a 100 Gbps paced connection with
a 2 GB send buffer could be throttled to ~26 Gbps.

>  	msk->snd_burst = burst;
>  	return ssk;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817-mptcp_penalise_send_v2-v3-0-e6a2ad2f1b82@mpiricsoftware.com?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.