From: David Laight <david.laight.linux@gmail.com>
To: Tao Cui <cui.tao@linux.dev>
Cc: axboe@kernel.dk, tj@kernel.org, josef@toxicpanda.com,
cgroups@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, Tao Cui <cuitao@kylinos.cn>
Subject: Re: [PATCH 1/2] blk-throttle: avoid ilog2(0) in calculate_bytes_allowed()
Date: Tue, 14 Jul 2026 12:32:44 +0100 [thread overview]
Message-ID: <20260714123244.69fbec98@pumpkin> (raw)
In-Reply-To: <20260714103028.1334831-2-cui.tao@linux.dev>
On Tue, 14 Jul 2026 18:30:27 +0800
Tao Cui <cui.tao@linux.dev> wrote:
> From: Tao Cui <cuitao@kylinos.cn>
>
> __tg_update_carryover() can call calculate_bytes_allowed() with a zero
> jiffy_elapsed right after a slice starts. The overflow guard
>
> if (ilog2(bps_limit) + ilog2(jiffy_elapsed) - ilog2(HZ) > 62)
>
> relies on ilog2(0) == -1 (fls64(0) - 1) to stay below the threshold so
> that the subsequent mul_u64_u64_div_u64(bps, 0, HZ) == 0 is reached.
> That works, but the ilog2(0) dependency is non-obvious.
>
> Add an explicit early return for jiffy_elapsed == 0, which is equivalent
> (mul_u64_u64_div_u64(bps_limit, 0, HZ) == 0) and removes the reliance on
> ilog2(0).
>
> No behavior change.
There is a pending patch to make the x86-64 mul_u64_u64_div_u64()
return ~0ULL on overflow to match the generic code.
That would completely remove the requirement for the overflow guard.
I can't remember why it got lost (again).
There have been arguments about what should happen for divide by zero.
Personally I'd return ~0ULL and let the caller decide what that means,
but the generic mul_u64_u64_div_u64() goes to lengths to generate any
trap that a normal divide by zero would generate.
David
>
> Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> ---
> block/blk-throttle.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> index ffc3b70065d4..f37911abefdd 100644
> --- a/block/blk-throttle.c
> +++ b/block/blk-throttle.c
> @@ -603,6 +603,10 @@ static unsigned int calculate_io_allowed(u32 iops_limit,
>
> static u64 calculate_bytes_allowed(u64 bps_limit, unsigned long jiffy_elapsed)
> {
> + /* 0 elapsed => 0 bytes allowed; also avoids ilog2(0) below. */
> + if (!jiffy_elapsed)
> + return 0;
> +
> /*
> * Can result be wider than 64 bits?
> * We check against 62, not 64, due to ilog2 truncation.
next prev parent reply other threads:[~2026-07-14 11:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 10:30 [PATCH 0/2] blk-throttle: minor cleanups Tao Cui
2026-07-14 10:30 ` [PATCH 1/2] blk-throttle: avoid ilog2(0) in calculate_bytes_allowed() Tao Cui
2026-07-14 11:32 ` David Laight [this message]
2026-07-14 10:30 ` [PATCH 2/2] blk-throttle: factor out limit field printing in tg_prfill_limit() Tao Cui
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=20260714123244.69fbec98@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox