On Thu, 03 Sep 2026 15:41:51 +0800, [email protected] wrote:
> [Severity: High]
> This is a pre-existing issue, but could this calculation trigger a division
> by zero kernel panic if denom is 0?
[...]
> Would it make sense to add an early return to check if refresh_hz evaluates
> to 0 before proceeding with these calculations?
The arithmetic is right: refresh_hz == 0 gives denom == 0, which divides
by zero both in the div_u64() and in the 100000/refresh_hz check a few
lines below.
As noted, it is pre-existing. The original code divided by the same
denom, so this patch does not change that exposure in either direction.
For it to trigger, refresh_hz = pix_clk_100hz * 100 / (v_total * h_total)
would have to truncate to zero, i.e. a mode below 1 Hz. This block only
runs for a single active stream that has already passed the MALL
eligibility checks above it, and with VRR the v_total used here is
adjust.v_total_max, which corresponds to the panel's minimum refresh
(48 Hz on the display I tested). I could not construct a case where a
live stream reaches this point with refresh_hz == 0.
I would rather not fold a guard into this patch: it carries a Fixes: tag
for the underflow, and the two problems are independent. If the
hardening is wanted I am happy to send it separately, something like
if (!refresh_hz)
return false;
before denom is computed.
Thanks,
Francis
