Re: [PATCH 1/2] blk-throttle: avoid ilog2(0) in calculate_bytes_allowed()
David Laight <[email protected]>
| Newsgroups | org.kernel.vger.cgroups,org.kernel.vger.linux-block,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260714123244.69fbec98@pumpkin> |
On Tue, 14 Jul 2026 18:30:27 +0800 Tao Cui <[email protected]> wrote: > From: Tao Cui <[email protected]> > > __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 <[email protected]> > --- > 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.