All of lore.kernel.org
 help / color / mirror / Atom feed
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 v5 1/3] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
Date: Mon, 12 Oct 2026 06:07:14 +0000	[thread overview]
Message-ID: <sashiko-outbox-167710@kernel.org> (raw)
In-Reply-To: <20261012055053.964468-6-satyanarayana.k.v.p@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: NULL pointer dereference due to incomplete locking in hw_engine_fini
--

commit 888f9d1be166404e1216f8d0d23505412e283b23
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 fixes a NULL pointer dereference by invalidating the engine
name and GT pointer during teardown in hw_engine_fini() under the
irq.lock, preventing the VF memory IRQ handler from scanning it.

> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
> index 265f95c0c8993..55ee0c892c1e8 100644
> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c

[ ... ]

> @@ -275,11 +275,22 @@ static const struct engine_info engine_infos[] = {
>  static void hw_engine_fini(void *arg)
>  {
>  	struct xe_hw_engine *hwe = arg;
> +	struct xe_gt *gt = hwe->gt;
> +
> +	if (gt) {
> +		struct xe_device *xe = gt_to_xe(gt);
> +		unsigned long flags;
>  
> -	if (hwe->exl_port)
> -		xe_execlist_port_destroy(hwe->exl_port);
> +		if (hwe->exl_port)
> +			xe_execlist_port_destroy(hwe->exl_port);
>  
> -	hwe->gt = NULL;
> +		spin_lock_irqsave(&xe->irq.lock, flags);
> +		hwe->name = NULL;
> +		hwe->gt = NULL;

[Severity: High]
Can this still cause a NULL pointer dereference for lockless IOCTL callers?

Unprivileged userspace can call the DRM_IOCTL_XE_DEVICE_QUERY ioctl
(specifically query_engine_cycles) concurrently with device unbind or unplug.
Since the ioctl is not guarded by drm_dev_enter(), it can proceed
concurrently with devres_release_all() and hw_engine_fini().

The ioctl looks up the hardware engine via xe_gt_hw_engine() in
query_engine_cycles():

drivers/gpu/drm/xe/xe_query.c:query_engine_cycles() {
    ...
    hwe = xe_gt_hw_engine(gt, user_to_xe_engine_class[eci->engine_class],
                          eci->engine_instance, true);
    if (!hwe)
        return -EINVAL;
    ...
}

Immediately after this check, hw_engine_fini() can execute and clear
hwe->gt = NULL (guarded only by xe->irq.lock, which the ioctl does not hold).

The ioctl then calls hwe_read_timestamp(), which dereferences hwe->gt:

drivers/gpu/drm/xe/xe_query.c:hwe_read_timestamp() {
    struct xe_mmio *mmio = &hwe->gt->mmio;
    ...
}

Does this lockless path need additional protection against concurrent
teardown?

> +		spin_unlock_irqrestore(&xe->irq.lock, flags);
> +	} else {
> +		hwe->name = NULL;
> +	}
>  }
>  
>  /**

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012055053.964468-5-satyanarayana.k.v.p@intel.com?part=1

  reply	other threads:[~2026-10-12  6:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12  5:50 [PATCH v5 0/3] Fix kernel crash during driver teardown Satyanarayana K V P
2026-10-12  5:50 ` [PATCH v5 1/3] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine Satyanarayana K V P
2026-10-12  6:07   ` sashiko-bot [this message]
2026-10-12  8:29   ` Piotr Piórkowski
2026-10-12  5:50 ` [PATCH v5 2/3] drm/xe/guc: Protect timeout handling from device unplug Satyanarayana K V P
2026-10-12  6:00   ` sashiko-bot
2026-10-12  5:50 ` [PATCH v5 3/3] drm/xe/gt: Disable GT reset worker before engine teardown Satyanarayana K V P
2026-10-12  8:40   ` Piotr Piórkowski

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-167710@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.