From: sashiko-bot@kernel.org
To: "Alexander Usyskin" <alexander.usyskin@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/xe/nvm: define survivabilty partition
Date: Wed, 15 Jul 2026 14:32:02 +0000 [thread overview]
Message-ID: <20260715143203.372901F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260715-cri_surviv-v1-2-61763a6f1076@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Enabling the survivability region causes an infinite loop during erase operations at the 8MB boundary, and bypasses bounds checks via integer underflow on reads and writes.
--
--- Patch [2]: [PATCH 2/2] drm/xe/nvm: define survivabilty partition ---
commit b38b020b9c762ee5ac9265db46b43fe2139de54d
Author: Alexander Usyskin <alexander.usyskin@intel.com>
drm/xe/nvm: define survivabilty partition
Define 8M survivability partition for CRI when
storage is open for write.
> diff --git a/drivers/gpu/drm/xe/xe_nvm.c b/drivers/gpu/drm/xe/xe_nvm.c
> index 1ea67eaeae243..54de0dbe1fa4d 100644
> --- a/drivers/gpu/drm/xe/xe_nvm.c
> +++ b/drivers/gpu/drm/xe/xe_nvm.c
[ ... ]
> @@ -67,6 +68,7 @@ static bool xe_nvm_writable_override(struct xe_device *xe)
> reg = PCODE_SCRATCH(0);
> test_bit = FDO_MODE;
> test_val = FDO_MODE;
> + s_size = SZ_8M;
[Severity: High]
Does enabling this survivability region cause an infinite loop during erase
operations in the MTD driver?
When this patch sets the size to 8MB and survivability is enabled, all
accesses are forced to use region 0, which has a hardcoded size of 8MB:
drivers/mtd/devices/mtd_intel_dg.c:idg_nvm_get_region() {
...
if (nvm->survivability_enabled)
return 0;
...
}
If a user performs an erase operation at or crossing the 8MB boundary, it can
trigger an infinite loop in intel_dg_mtd_erase():
drivers/mtd/devices/mtd_intel_dg.c:intel_dg_mtd_erase() {
...
if (len > nvm->regions[idx].size - from)
len = nvm->regions[idx].size - from;
...
}
When from reaches 8MB (the size of region 0), size - from evaluates to 0. This
sets len to 0. This can cause the operation to return 0 immediately without
decreasing total_len, leading to an infinite while (total_len > 0) loop.
Additionally, read and write operations starting beyond 8MB might cause
size - from to underflow to a massive positive number, bypassing bounds checks.
> break;
> case XE_BATTLEMAGE:
> reg = HECI_FWSTS2(DG2_GSC_HECI2_BASE);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-cri_surviv-v1-0-61763a6f1076@intel.com?part=2
next prev parent reply other threads:[~2026-07-15 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 13:45 [PATCH 0/2] drm/xe/nvm: add survivabilty partiton Alexander Usyskin
2026-07-15 13:45 ` Alexander Usyskin
2026-07-15 13:45 ` [PATCH 1/2] mtd: mtd_intel_dg: add survivability partition Alexander Usyskin
2026-07-15 13:45 ` Alexander Usyskin
2026-07-15 14:19 ` sashiko-bot
2026-07-15 13:45 ` [PATCH 2/2] drm/xe/nvm: define survivabilty partition Alexander Usyskin
2026-07-15 13:45 ` Alexander Usyskin
2026-07-15 14:32 ` sashiko-bot [this message]
2026-07-15 14:53 ` ✓ CI.KUnit: success for drm/xe/nvm: add survivabilty partiton Patchwork
2026-07-15 15:33 ` ✓ Xe.CI.BAT: " 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=20260715143203.372901F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alexander.usyskin@intel.com \
--cc=dri-devel@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.