Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221118 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by commits:
Thu Nov 17 16:12:56 2022 +0200
62749912540b ("drm/i915/display: move hti under display sub-struct")
Coverity reported the following:
*** CID 1527374: Integer handling issues (BAD_SHIFT)
drivers/gpu/drm/i915/display/intel_hti.c:24 in intel_hti_uses_phy()
18 if (INTEL_INFO(i915)->display.has_hti)
19 i915->display.hti.state = intel_de_read(i915, HDPORT_STATE);
20 }
21
22 bool intel_hti_uses_phy(struct drm_i915_private *i915, enum phy phy)
23 {
vvv CID 1527374: Integer handling issues (BAD_SHIFT)
vvv In expression "1UL << 2 * phy + 1", shifting by a negative amount has undefined behavior. The shift amount, "2 * phy + 1", is as little as -1.
24 return i915->display.hti.state & HDPORT_ENABLED &&
25 i915->display.hti.state & HDPORT_DDI_USED(phy);
26 }
27
28 u32 intel_hti_dpll_mask(struct drm_i915_private *i915)
29 {
If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):
Reported-by: coverity-bot <[email protected]>
Addresses-Coverity-ID: 1527374 ("Integer handling issues")
Fixes: 62749912540b ("drm/i915/display: move hti under display sub-struct")
This code appears to be safe currently (intel_hti_uses_phy() is never
called with PHY_NONE), but perhaps add an explicit check?
if (WARN_ON(phy == PHY_NONE))
return false;
Thanks for your attention!
--
Coverity-bot
On Fri, 18 Nov 2022, coverity-bot <[email protected]> wrote:
> Hello!
>
> This is an experimental semi-automated report about issues detected by
> Coverity from a scan of next-20221118 as part of the linux-next scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
>
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by commits:
>
> Thu Nov 17 16:12:56 2022 +0200
> 62749912540b ("drm/i915/display: move hti under display sub-struct")
>
> Coverity reported the following:
>
> *** CID 1527374: Integer handling issues (BAD_SHIFT)
> drivers/gpu/drm/i915/display/intel_hti.c:24 in intel_hti_uses_phy()
> 18 if (INTEL_INFO(i915)->display.has_hti)
> 19 i915->display.hti.state = intel_de_read(i915, HDPORT_STATE);
> 20 }
> 21
> 22 bool intel_hti_uses_phy(struct drm_i915_private *i915, enum phy phy)
> 23 {
> vvv CID 1527374: Integer handling issues (BAD_SHIFT)
> vvv In expression "1UL << 2 * phy + 1", shifting by a negative amount has undefined behavior. The shift amount, "2 * phy + 1", is as little as -1.
> 24 return i915->display.hti.state & HDPORT_ENABLED &&
> 25 i915->display.hti.state & HDPORT_DDI_USED(phy);
> 26 }
> 27
> 28 u32 intel_hti_dpll_mask(struct drm_i915_private *i915)
> 29 {
>
> If this is a false positive, please let us know so we can mark it as
> such, or teach the Coverity rules to be smarter. If not, please make
> sure fixes get into linux-next. :) For patches fixing this, please
> include these lines (but double-check the "Fixes" first):
>
> Reported-by: coverity-bot <[email protected]>
> Addresses-Coverity-ID: 1527374 ("Integer handling issues")
> Fixes: 62749912540b ("drm/i915/display: move hti under display sub-struct")
Thanks for the report, fix at [1].
I realize I didn't use the suggested tags above. For one thing, we've
never really logged any proprietary tools used. Looks like
"Addresses-Coverity-ID:" is growing in popularity though.
The Fixes: tag points at code refactoring, it was a pre-existing
condition.
BR,
Jani.
[1] https://patchwork.freedesktop.org/patch/msgid/[email protected]
>
> This code appears to be safe currently (intel_hti_uses_phy() is never
> called with PHY_NONE), but perhaps add an explicit check?
>
> if (WARN_ON(phy == PHY_NONE))
> return false;
>
> Thanks for your attention!
--
Jani Nikula, Intel Open Source Graphics Center