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 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.