[PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow

[Chris Wilson]

Quoting Ville Syrjala (2020-10-22 20:42:56)
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> means our clock*1000 will now overflow the 32bit unsigned
> integer. Switch to 64bit maths to avoid it.
> 
> Cc: stable at vger.kernel.org
> Reported-by: Randy Dunlap <rdunlap at infradead.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
> An interesting question how many other place might suffer from similar
> overflows. I think i915 should be mostly OK. The one place I know we use
> Hz instead kHz is the hsw DPLL code, which I would prefer we also change
> to use kHz. The other concern is whether we have any potential overflows
> before we check this against the platform's max dotclock.
> 
> I do have this unreviewed igt series 
> https://patchwork.freedesktop.org/series/69531/ which extends the
> current testing with some other forms of invalid modes. Could probably
> extend that with a mode.clock=INT_MAX test to see if anything else might
> trip up.
> 
> No idea about other drivers.
> 
>  drivers/gpu/drm/drm_modes.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 501b4fe55a3d..511cde5c7fa6 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -762,7 +762,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
>         if (mode->htotal == 0 || mode->vtotal == 0)
>                 return 0;
>  
> -       num = mode->clock * 1000;
> +       num = mode->clock;
>         den = mode->htotal * mode->vtotal;

You don't want to promote den to u64 while you are here? We are at
8kx4k, throw in dblscan and some vscan, and we could soon have wacky
refresh rates.
-Chris