All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shardul Bankar" <shardul.b@mpiricsoftware.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v3 1/4] mptcp: sched: avoid truncating the pacing rate in the scheduler
Date: Mon, 17 Aug 2026 15:40:04 +0000	[thread overview]
Message-ID: <20260817154005.1E1591F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260817-mptcp_penalise_send_v2-v3-1-e6a2ad2f1b82@mpiricsoftware.com>

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 <shardul.b@mpiricsoftware.com>

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

  reply	other threads:[~2026-08-17 15:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 15:24 [PATCH mptcp-next v3 0/4] mptcp: sched: penalise a slow subflow Shardul Bankar
2026-08-17 15:24 ` [PATCH mptcp-next v3 1/4] mptcp: sched: avoid truncating the pacing rate in the scheduler Shardul Bankar
2026-08-17 15:40   ` sashiko-bot [this message]
2026-08-17 15:24 ` [PATCH mptcp-next v3 2/4] mptcp: sched: penalise a slow subflow by halving its cwnd Shardul Bankar
2026-08-17 15:39   ` sashiko-bot
2026-08-17 15:24 ` [PATCH mptcp-next v3 3/4] mptcp: sched: do not penalise when receive-window-limited Shardul Bankar
2026-08-17 15:36   ` sashiko-bot
2026-08-17 15:24 ` [PATCH mptcp-next v3 4/4] mptcp: sched: add penalise counters and tracepoint Shardul Bankar
2026-08-17 15:34   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260817154005.1E1591F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shardul.b@mpiricsoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.