All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Tejas Upadhyay <tejas.upadhyay@intel.com>
Cc: intel-xe@lists.freedesktop.org, himal.prasad.ghimiray@intel.com,
	matthew.brost@intel.com, arvind.yadav@intel.com
Subject: Re: [PATCH] drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort
Date: Fri, 13 Nov 2026 16:20:11 +0100	[thread overview]
Message-ID: <avcqq9J7MHnVKlWv@black.igk.intel.com> (raw)
In-Reply-To: <20261113132149.2989667-2-tejas.upadhyay@intel.com>

On Fri, Nov 13, 2026 at 06:51:50PM +0530, Tejas Upadhyay wrote:
> xe_guc_submit_pause_abort() walks guc->submission_state.exec_queue_lookup
> and unconditionally calls guc_exec_queue_kill() on every entry found,
> without verifying the queue hasn't already begun/finished its own
> independent teardown. guc_exec_queue_fini() (run once a queue's own
> refcount drops to zero via the normal close path) only erases its xarray
> entry partway through its body, via release_guc_id() -- so there is a
> window where a queue's refcount is already 0 but its xarray entry is
> still present.
> 
> This was caught as a debug assertion firing on both BMG and CRI:
> 
> 	xe 0000:00:03.0: [drm] Assertion `kref_read(&q->refcount)` failed!
> 	WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:2242 at guc_exec_queue_kill+0x2e2/0x360 [xe]
> 	Call Trace:
> 	 guc_exec_queue_kill+0x2e2/0x360 [xe]
> 	 xe_guc_submit_pause_abort+0x8e/0xf0 [xe]
> 	 guc_submit_fini+0x11f/0x180 [xe]
> 	 devm_action_release+0x15/0x30
> 	 ...
> 	 device_release_driver_internal+0x230/0x270
> 	 unbind_store+0xac/0xc0                          [BMG: igt@xe_configfs, sysfs unbind]
> 	 pci_iov_remove_virtfn+0xd1/0x140
> 	 sriov_disable+0x42/0x100
> 	 pci_disable_sriov+0x23/0x40
> 	 xe_pci_sriov_configure+0x2b9/0x1350 [xe]
> 	 sriov_numvfs_store+0x136/0x1f0           [CRI: igt@xe_pmu, SR-IOV VF disable]
> 
> Pin the queue with kref_get_unless_zero() before touching it, skipping entries
> that have already independently reached a zero refcount instead of operating on
> an object that's already being torn down elsewhere.
> 
> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_guc_submit.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index d76f125f9c3a..7a3bd698f217 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -3306,12 +3306,18 @@ void xe_guc_submit_pause_abort(struct xe_guc *guc)
>  	xa_for_each(&guc->submission_state.exec_queue_lookup, index, q) {
>  		struct xe_gpu_scheduler *sched = &q->guc->sched;
>  
> -		/* Prevent redundant attempts to stop parallel queues */
> -		if (q->guc->id != index)
> +		/*
> +		 * Prevent redundant attempts to stop parallel queues, and skip
> +		 * queues already dropped to a zero refcount via their own
> +		 * independent teardown (guc_exec_queue_fini(), xarray entry
> +		 * not yet erased)
> +		 */
> +		if (q->guc->id != index || !kref_get_unless_zero(&q->refcount))
>  			continue;
>  
>  		xe_sched_submission_start(sched);
>  		guc_exec_queue_kill(q);
> +		xe_exec_queue_put(q);

Please make sure this doesn't regress FLR flow, where we need to keep
the exec queues around to reinit them later.

Raag

>  	}
>  	mutex_unlock(&guc->submission_state.lock);
>  }
> -- 
> 2.52.0
> 

  parent reply	other threads:[~2026-11-13 15:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 13:21 [PATCH] drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort Tejas Upadhyay
2026-11-13 13:46 ` sashiko-bot
2026-11-13 15:53   ` Matthew Brost
2026-11-13 13:58 ` ✗ CI.checkpatch: warning for " Patchwork
2026-11-13 14:00 ` ✓ CI.KUnit: success " Patchwork
2026-11-13 14:31 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-13 15:20 ` Raag Jadav [this message]
2026-11-13 15:55 ` [PATCH] " Matthew Brost

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=avcqq9J7MHnVKlWv@black.igk.intel.com \
    --to=raag.jadav@intel.com \
    --cc=arvind.yadav@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=tejas.upadhyay@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.