From: sashiko-bot@kernel.org
To: "Gustavo Sousa" <gustavo.sousa@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 04/10] drm/xe: Factor out {min,max}_idledly_ps in adjust_idledly()
Date: Fri, 23 Oct 2026 21:23:04 +0000 [thread overview]
Message-ID: <sashiko-outbox-183251@kernel.org> (raw)
In-Reply-To: <20261023-wa_16031259911-v1-4-b0453f79c4e1@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: 32-bit multiplication overflow in adjust_idledly()
--
commit 032b173104de210ca0228dd31e057951f3cde20d
Author: Gustavo Sousa <gustavo.sousa@intel.com>
drm/xe: Factor out {min,max}_idledly_ps in adjust_idledly()
This commit reorganizes adjust_idledly() so that workaround-specific logic
computes min_idledly_ps and max_idledly_ps before applying and rounding
those limits to the RING_IDLEDLY register field.
> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
> index dcc8a6d53c5d0..2d2a80cc2da35 100644
> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c
> @@ -585,99 +585,81 @@ static void hw_engine_init_early(struct xe_gt *gt, struct xe_hw_engine *hwe,
> xe_reg_whitelist_process_engine(hwe);
> }
>
> -static u32 idledly_floor_ticks(u64 idledly_ps, u32 idledly_units_ps)
> -{
> - return DIV_ROUND_DOWN_ULL(idledly_ps, idledly_units_ps);
> -}
> -
> static void adjust_idledly(struct xe_hw_engine *hwe)
> {
> struct xe_gt *gt = hwe->gt;
> - u32 idledly_reg_val, maxcnt_reg_val;
> + u32 idledly_reg_val;
> + u32 idledly;
> u32 idledly_units_ps = 8 * gt->info.timestamp_base;
> - u32 maxcnt_units_ps = 640000;
> u64 idledly_ps, idledly_hw_ps;
> - u64 maxcnt_ps;
> + u64 min_idledly_ps = 0;
> + u64 max_idledly_ps = -1;
> bool inhibit_switch = false;
> bool wa_applied = false;
> - bool clamped_below_maxcnt = false;
>
> if (IS_SRIOV_VF(gt_to_xe(gt)))
> return;
>
> if (XE_GT_WA(gt, 16023105232) || XE_GT_WA(gt, 14025941587)) {
> - u32 mincnt_idledly_ps = 5000000;
> -
> /* xe_gt_clock_init() warns and zeroes timestamp_base on unknown crystal clock. */
> if (!idledly_units_ps)
> return;
>
> idledly_reg_val = xe_mmio_read32(>->mmio, RING_IDLEDLY(hwe->mmio_base));
> inhibit_switch = idledly_reg_val & INHIBIT_SWITCH_UNTIL_PREEMPTED;
> - idledly_ps = REG_FIELD_GET(IDLE_DELAY, idledly_reg_val) * idledly_units_ps;
> + idledly = REG_FIELD_GET(IDLE_DELAY, idledly_reg_val);
> + idledly_ps = idledly * idledly_units_ps;
> idledly_hw_ps = idledly_ps;
>
> - maxcnt_reg_val = xe_mmio_read32(>->mmio, RING_PWRCTX_MAXCNT(hwe->mmio_base));
> - maxcnt_ps = REG_FIELD_GET(IDLE_WAIT_TIME, maxcnt_reg_val) * maxcnt_units_ps;
> -
> - /*
> - * Wa_14025941587 is applied before Wa_16023105232, which takes
> - * priority if the two ever conflict (not expected in practice).
> - */
> - if (XE_GT_WA(gt, 14025941587) &&
> - idledly_ps < mincnt_idledly_ps) {
> - idledly_ps = mincnt_idledly_ps;
> - wa_applied = true;
> - }
> + if (XE_GT_WA(gt, 14025941587))
> + min_idledly_ps = max(min_idledly_ps, 5000000);
>
> if (XE_GT_WA(gt, 16023105232)) {
> + u32 maxcnt_units_ps = 640000;
> + u32 maxcnt = xe_mmio_read32(>->mmio, RING_PWRCTX_MAXCNT(hwe->mmio_base));
> +
> + max_idledly_ps = min_t(u64,
> + max_idledly_ps,
> + REG_FIELD_GET(IDLE_WAIT_TIME, maxcnt) * maxcnt_units_ps);
> +
> /* Clear the inhibit switch without disturbing a valid delay. */
> if (inhibit_switch) {
> idledly_reg_val &= ~INHIBIT_SWITCH_UNTIL_PREEMPTED;
> wa_applied = true;
> }
> + }
>
> - /* Warn only on the value read from hardware. */
> - xe_gt_WARN_ON(gt, idledly_hw_ps >= maxcnt_ps);
> + /*
> + * min_idledly_ps is applied before max_idledly_ps, which takes
> + * priority if the two ever conflict (not expected in practice).
> + */
> + if (idledly_ps < min_idledly_ps) {
> + idledly = DIV_ROUND_UP_ULL(min_idledly_ps, idledly_units_ps);
> + idledly_ps = idledly * idledly_units_ps;
> + wa_applied = true;
> + }
>
> - if (idledly_ps >= maxcnt_ps) {
> - /* maxcnt may be 0 if IDLE_WAIT_TIME is unprogrammed. */
> - idledly_ps = maxcnt_ps ? maxcnt_ps - 1 : 0;
> - clamped_below_maxcnt = true;
> - wa_applied = true;
> + if (idledly_ps >= max_idledly_ps) {
> + if (max_idledly_ps) {
> + idledly = DIV_ROUND_DOWN_ULL(max_idledly_ps - 1, idledly_units_ps);
> + idledly_ps = idledly * idledly_units_ps;
[Severity: Medium]
Can these tick-to-picosecond multiplications in adjust_idledly() in
drivers/gpu/drm/xe/xe_hw_engine.c overflow 32 bits before being widened to
u64?
When hw_engine_init() calls adjust_idledly() on non-VF platforms where
Wa_16023105232 or Wa_14025941587 is active, idledly, idledly_units_ps (up to
8 * 83333 = 666,664 ps), maxcnt_units_ps (640,000 ps), and the return value
of REG_FIELD_GET(IDLE_WAIT_TIME, maxcnt) are all u32.
In the three assignments:
idledly_ps = idledly * idledly_units_ps;
both operands are u32. Since IDLE_DELAY is a 21-bit field (REG_GENMASK(20, 0),
up to 2,097,151 ticks), the product can reach ~1.398e12 ps and wraps modulo
2^32 for idledly >= 6443 ticks before assignment to u64 idledly_ps.
Similarly, in:
max_idledly_ps = min_t(u64,
max_idledly_ps,
REG_FIELD_GET(IDLE_WAIT_TIME, maxcnt) * maxcnt_units_ps);
REG_FIELD_GET(IDLE_WAIT_TIME, maxcnt) * maxcnt_units_ps is evaluated in 32-bit
unsigned arithmetic before min_t(u64, ...) casts the result to u64. Because
IDLE_WAIT_TIME is a 20-bit field (REG_GENMASK(19, 0), up to 1,048,575 ticks),
the product can reach ~6.71e11 ps and wraps 32 bits for IDLE_WAIT_TIME >= 6711
ticks, which can misprogram RING_IDLEDLY or trigger false
xe_gt_WARN_ON(gt, idledly_hw_ps >= max_idledly_ps) warnings.
Commit d864065ea25e ("drm/xe: harden adjust_idledly() against divide-by-zero
and overflow") previously added explicit (u64) casts to prevent 32-bit
truncation when converting ticks to time units. Should idledly_units_ps and
maxcnt_units_ps (or the multiplication operands) be promoted to u64 here as
well?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261023-wa_16031259911-v1-0-b0453f79c4e1@intel.com?part=4
next prev parent reply other threads:[~2026-10-23 21:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 21:09 [PATCH 00/10] drm/xe: Clean up adjust_idledly() and implement Wa_16031259911 Gustavo Sousa
2026-10-23 21:09 ` [PATCH 01/10] drm/xe: Bail from adjust_idledly() if in VF mode Gustavo Sousa
2026-10-27 19:15 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 02/10] drm/xe: Sync Wa_16023105232 in xe_was to match OOB rule Gustavo Sousa
2026-10-27 19:16 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 03/10] drm/xe: Use picosecond as common unit in adjust_idledly() Gustavo Sousa
2026-10-23 21:19 ` sashiko-bot
2026-10-23 22:00 ` Gustavo Sousa
2026-10-23 21:09 ` [PATCH 04/10] drm/xe: Factor out {min,max}_idledly_ps " Gustavo Sousa
2026-10-23 21:23 ` sashiko-bot [this message]
2026-10-27 19:22 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 05/10] drm/xe: Bail from adjust_idledly() if no applicable workaround Gustavo Sousa
2026-10-27 19:27 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 06/10] drm/xe: Drop early and redundant workaround checks in adjust_idledly() Gustavo Sousa
2026-10-23 21:22 ` sashiko-bot
2026-10-27 19:30 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 07/10] drm/xe: Drop comment about MAXCNT when calling adjust_idledly() Gustavo Sousa
2026-10-27 19:33 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 08/10] drm/xe/guc: Increment regset size for Wa_1607983814 inside hwe loop Gustavo Sousa
2026-10-27 19:39 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 09/10] drm/xe/guc: Increment regset size for RING_IDLEDLY workarounds Gustavo Sousa
2026-10-27 19:42 ` Matt Atwood
2026-10-23 21:09 ` [PATCH 10/10] drm/xe: Implement Wa_16031259911 Gustavo Sousa
2026-10-27 19:44 ` Matt Atwood
2026-10-23 21:20 ` ✗ CI.checkpatch: warning for drm/xe: Clean up adjust_idledly() and implement Wa_16031259911 Patchwork
2026-10-23 21:22 ` ✓ CI.KUnit: success " Patchwork
2026-10-23 21:58 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-24 6:44 ` ✗ Xe.CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-183251@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gustavo.sousa@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.