Re: [RFC PATCH v3 3/5] blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The tracepoint `iocost_ioc_tick` uses `div_u64()` with a 64-bit divisor (`tick_dur`), which implicitly truncates the divisor to 32 bits and can cause a divide-by-zero kernel panic.
--

commit 1f0b986a96c58d14982b08bd292007816d7d5b50
Author: Tao Cui <cuitao@kylinos.cn>

blk-iocost: add iocost_ioc_tick tracepoint for per-period device summary

This commit adds a new iocost_ioc_tick tracepoint to the blk-iocost
controller. It emits the overall controller state once per period from the
tail of ioc_timer_fn(). This allows observability of steady-state and
dormancy conditions without needing drgn to read kernel memory.

[ ... ]
> diff --git a/include/trace/events/iocost.h b/include/trace/events/iocost.h
> index e772b1bc60d60..ec5d9c453d55a 100644
> --- a/include/trace/events/iocost.h
> +++ b/include/trace/events/iocost.h
> @@ -178,6 +178,52 @@ TRACE_EVENT(iocost_ioc_vrate_adj,
[ ... ]
> +	TP_fast_assign(
> +		__assign_str(devname);
> +		__entry->cur_period = cur_period;
> +		__entry->period_us = tick_period_us;
> +		__entry->vrate = tick_vrate;
> +		__entry->busy_level = tick_busy;
> +		__entry->nr_active = nr_active;
> +		__entry->usage_pct = tick_dur ?
> +			div_u64(usage_us_sum * 100, tick_dur) : 0;

[Severity: High]
Could this lead to a division by zero kernel panic?

The div_u64() function expects a u32 divisor, but tick_dur is passed in as a
u64 representing a time delta in microseconds. If the system experiences a
long delay (such as a ~4294 second pause from a VM suspend/resume or a
debugger session), tick_dur can be a multiple of 2^32.

In that scenario, the full 64-bit value is non-zero, allowing it to pass
the tick_dur ? safety check. However, the implicit cast to u32 inside
div_u64() truncates the lower 32 bits to exactly 0, which would result in a
divide by zero panic when the tracepoint is evaluated.

Would it be better to use div64_u64() here to safely handle the 64-bit
divisor?

> +		__entry->running = tick_running;
> +	),
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914073356.791518-1-cui.tao@linux.dev?part=3