From: sashiko-bot@kernel.org
To: "Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 1/1] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
Date: Thu, 08 Oct 2026 15:52:12 +0000 [thread overview]
Message-ID: <sashiko-outbox-164360@kernel.org> (raw)
In-Reply-To: <20261008153425.607925-4-satyanarayana.k.v.p@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: TOCTOU NULL pointer dereference in DRM scheduler timeout handler during engine teardown
--
commit bc1cf6d3127f6708d4287d0a751daf2ee1c80dc6
Author: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
This commit clears the engine name during teardown to ensure that subsequent
hardware engine scans skip the invalidated engine. This prevents a NULL pointer
dereference in the VF memory IRQ handler when accessing torn-down engines.
> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c
[ ... ]
> @@ -275,6 +275,12 @@ static const struct engine_info engine_infos[] = {
> static void hw_engine_fini(void *arg)
> {
> struct xe_hw_engine *hwe = arg;
> + struct xe_device *xe = gt_to_xe(hwe->gt);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&xe->irq.lock, flags);
> + hwe->name = NULL;
> + spin_unlock_irqrestore(&xe->irq.lock, flags);
>
> if (hwe->exl_port)
> xe_execlist_port_destroy(hwe->exl_port);
[Severity: High]
While the new lock protects the IRQ handler, can a lockless reader like the DRM
scheduler timeout handler still encounter a time-of-check to time-of-use race?
If the timeout handler fires after a device unplug, it locklessly iterates over
the engines:
drivers/gpu/drm/xe/xe_gt.c:xe_gt_hw_engine() {
...
for_each_hw_engine(hwe, gt, id)
if (hwe->class == class && ...
...
}
The for_each_hw_engine iteration evaluates xe_hw_engine_is_valid, which checks
hwe->name. If this lockless check occurs right before hw_engine_fini clears
hwe->name, the timeout handler will proceed with the engine pointer.
Later in hw_engine_fini, hwe->gt is set to NULL. The timeout handler could
then dereference the null pointer when it calls into the LRC code:
drivers/gpu/drm/xe/xe_lrc.c:xe_lrc_get_multi_queue_active_queue_id() {
...
u32 val = xe_mmio_read32(&hwe->gt->mmio,
RING_CSMQDEBUG(hwe->mmio_base));
...
}
Does the lockless reader need additional synchronization to ensure hwe->gt
is safely accessed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008153425.607925-3-satyanarayana.k.v.p@intel.com?part=1
next prev parent reply other threads:[~2026-10-08 15:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 15:34 [PATCH v2 0/1] Fix kernel crash during driver teardown Satyanarayana K V P
2026-10-08 15:34 ` [PATCH v2 1/1] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine Satyanarayana K V P
2026-10-08 15:52 ` sashiko-bot [this message]
2026-10-08 19:39 ` ✓ Xe.CI.FULL: success for Fix kernel crash during driver teardown (rev2) 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-164360@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=satyanarayana.k.v.p@intel.com \
/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.