* [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
@ 2020-10-22 19:42 Ville Syrjala
2020-10-23 18:04 ` Randy Dunlap
2020-10-30 14:19 ` Chris Wilson
0 siblings, 2 replies; 5+ messages in thread
From: Ville Syrjala @ 2020-10-22 19:42 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Randy Dunlap, stable
From: Ville Syrjälä <ville.syrjala@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@vger.kernel.org
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@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;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -772,7 +772,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
if (mode->vscan > 1)
den *= mode->vscan;
- return DIV_ROUND_CLOSEST(num, den);
+ return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.26.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
2020-10-22 19:42 [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow Ville Syrjala
@ 2020-10-23 18:04 ` Randy Dunlap
2020-10-30 14:19 ` Chris Wilson
1 sibling, 0 replies; 5+ messages in thread
From: Randy Dunlap @ 2020-10-23 18:04 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: intel-gfx, stable
On 10/22/20 12:42 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@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@vger.kernel.org
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This cures the problem that I reported. Thanks.
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> 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;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> @@ -772,7 +772,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
> if (mode->vscan > 1)
> den *= mode->vscan;
>
> - return DIV_ROUND_CLOSEST(num, den);
> + return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
> }
> EXPORT_SYMBOL(drm_mode_vrefresh);
>
>
--
~Randy
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
2020-10-22 19:42 [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow Ville Syrjala
2020-10-23 18:04 ` Randy Dunlap
@ 2020-10-30 14:19 ` Chris Wilson
2020-10-30 14:43 ` Ville Syrjälä
1 sibling, 1 reply; 5+ messages in thread
From: Chris Wilson @ 2020-10-30 14:19 UTC (permalink / raw)
To: Ville Syrjala, dri-devel; +Cc: intel-gfx, Randy Dunlap, stable
Quoting Ville Syrjala (2020-10-22 20:42:56)
> From: Ville Syrjälä <ville.syrjala@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@vger.kernel.org
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
2020-10-30 14:19 ` Chris Wilson
@ 2020-10-30 14:43 ` Ville Syrjälä
2020-11-25 19:44 ` Chris Wilson
0 siblings, 1 reply; 5+ messages in thread
From: Ville Syrjälä @ 2020-10-30 14:43 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, Randy Dunlap, stable, dri-devel
On Fri, Oct 30, 2020 at 02:19:45PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-10-22 20:42:56)
> > From: Ville Syrjälä <ville.syrjala@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@vger.kernel.org
> > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@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.
i915 has 16kx8k hard limit currently, and we reject vscan>1
(wish we could also reject DBLSCAN). So we should not hit
that, at least not yet. Other drivers might not be so strict
I guess.
I have a nagging feeling that other places are in danger of
overflows if we try to push the current limits significantly.
But I guess no real harm in going full 64bit here, except
maybe making it a bit slower.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow
2020-10-30 14:43 ` Ville Syrjälä
@ 2020-11-25 19:44 ` Chris Wilson
0 siblings, 0 replies; 5+ messages in thread
From: Chris Wilson @ 2020-11-25 19:44 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, Randy Dunlap, stable, dri-devel
Quoting Ville Syrjälä (2020-10-30 14:43:46)
> On Fri, Oct 30, 2020 at 02:19:45PM +0000, Chris Wilson wrote:
> > Quoting Ville Syrjala (2020-10-22 20:42:56)
> > > From: Ville Syrjälä <ville.syrjala@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@vger.kernel.org
> > > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@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.
>
> i915 has 16kx8k hard limit currently, and we reject vscan>1
> (wish we could also reject DBLSCAN). So we should not hit
> that, at least not yet. Other drivers might not be so strict
> I guess.
>
> I have a nagging feeling that other places are in danger of
> overflows if we try to push the current limits significantly.
> But I guess no real harm in going full 64bit here, except
> maybe making it a bit slower.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-25 19:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-22 19:42 [PATCH] drm/modes: Switch to 64bit maths to avoid integer overflow Ville Syrjala
2020-10-23 18:04 ` Randy Dunlap
2020-10-30 14:19 ` Chris Wilson
2020-10-30 14:43 ` Ville Syrjälä
2020-11-25 19:44 ` Chris Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).