Message ID | 20210322160253.4032422-11-arnd@kernel.org (mailing list archive) |
---|---|
State | Not Applicable |
Delegated to: | Johannes Berg |
Headers | show |
Series | treewide: address gcc-11 -Wstringop-overread warnings | expand |
On Mon, 22 Mar 2021, Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > gcc-11 warns about what appears to be an out-of-range array access: > > In function ‘snb_wm_latency_quirk’, > inlined from ‘ilk_setup_wm_latency’ at drivers/gpu/drm/i915/intel_pm.c:3108:3: > drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Werror=stringop-overread] > 3057 | intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’: > drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of type ‘const u16 *’ {aka ‘const short unsigned int *’} > drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function ‘intel_print_wm_latency’ > 2994 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv, > | ^~~~~~~~~~~~~~~~~~~~~~ > > My guess is that this code is actually safe because the size of the > array depends on the hardware generation, and the function checks for > that, but at the same time I would not expect the compiler to work it > out correctly, and the code seems a little fragile with regards to > future changes. Simply increasing the size of the array should help. Agreed, I don't think there's an issue, but the code could use a bunch of improvements. Like, we have intel_print_wm_latency() for debug logging and wm_latency_show() for debugfs, and there's a bunch of duplication and ugh. But this seems like the easiest fix for the warning. Reviewed-by: Jani Nikula <jani.nikula@intel.com> > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/gpu/drm/i915/i915_drv.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 26d69d06aa6d..3567602e0a35 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1095,11 +1095,11 @@ struct drm_i915_private { > * in 0.5us units for WM1+. > */ > /* primary */ > - u16 pri_latency[5]; > + u16 pri_latency[8]; > /* sprite */ > - u16 spr_latency[5]; > + u16 spr_latency[8]; > /* cursor */ > - u16 cur_latency[5]; > + u16 cur_latency[8]; > /* > * Raw watermark memory latency values > * for SKL for all 8 levels
On Wed, Mar 24, 2021 at 05:30:24PM +0200, Jani Nikula wrote: > On Mon, 22 Mar 2021, Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > gcc-11 warns about what appears to be an out-of-range array access: > > > > In function ‘snb_wm_latency_quirk’, > > inlined from ‘ilk_setup_wm_latency’ at drivers/gpu/drm/i915/intel_pm.c:3108:3: > > drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Werror=stringop-overread] > > 3057 | intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency); > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’: > > drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of type ‘const u16 *’ {aka ‘const short unsigned int *’} > > drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function ‘intel_print_wm_latency’ > > 2994 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv, > > | ^~~~~~~~~~~~~~~~~~~~~~ > > > > My guess is that this code is actually safe because the size of the > > array depends on the hardware generation, and the function checks for > > that, but at the same time I would not expect the compiler to work it > > out correctly, and the code seems a little fragile with regards to > > future changes. Simply increasing the size of the array should help. > > Agreed, I don't think there's an issue, but the code could use a bunch > of improvements. > > Like, we have intel_print_wm_latency() for debug logging and > wm_latency_show() for debugfs, and there's a bunch of duplication and > ugh. There is all this ancient stuff in review limbo... https://patchwork.freedesktop.org/series/50802/
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 26d69d06aa6d..3567602e0a35 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1095,11 +1095,11 @@ struct drm_i915_private { * in 0.5us units for WM1+. */ /* primary */ - u16 pri_latency[5]; + u16 pri_latency[8]; /* sprite */ - u16 spr_latency[5]; + u16 spr_latency[8]; /* cursor */ - u16 cur_latency[5]; + u16 cur_latency[8]; /* * Raw watermark memory latency values * for SKL for all 8 levels