From: Matthew Brost <matthew.brost@intel.com>
To: Arvind Yadav <arvind.yadav@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<himal.prasad.ghimiray@intel.com>,
<thomas.hellstrom@linux.intel.com>, <rodrigo.vivi@intel.com>,
<tejas.upadhyay@intel.com>
Subject: Re: [PATCH] drm/xe: Account for exec queue cleanup after handle allocation fails
Date: Fri, 13 Nov 2026 10:27:34 -0800 [thread overview]
Message-ID: <avdWloP416vGgEgT@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20261113065437.249640-1-arvind.yadav@intel.com>
On Fri, Nov 13, 2026 at 12:24:36PM +0530, Arvind Yadav wrote:
> xe_exec_queue_create_ioctl() assigns q->xef before allocating the
> userspace handle. If xa_alloc() fails, queue finalization decrements
> pending_removal even though the queue was never removed from the
> xarray and the counter was never incremented.
>
> This can leave pending_removal negative and block fdinfo readers
> waiting for it to reach zero.
>
> Increment pending_removal before unwinding the failed allocation.
> The existing finalization path balances the increment.
>
> Fixes: 0fd4380c050d ("drm/xe: Wait on killed exec queues")
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
> Assisted-by: LLM
> Closes: https://sashiko.dev/#/bug/linux-0e3ad548-c571-43d0-bf6b-00ed4771bd7a
> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
> ---
> drivers/gpu/drm/xe/xe_exec_queue.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c
> index 7ade915c59a8..39d99d6d418c 100644
> --- a/drivers/gpu/drm/xe/xe_exec_queue.c
> +++ b/drivers/gpu/drm/xe/xe_exec_queue.c
> @@ -1471,8 +1471,14 @@ int xe_exec_queue_create_ioctl(struct drm_device *dev, void *data,
>
> /* user id alloc must always be last in ioctl to prevent UAF */
> err = xa_alloc(&xef->exec_queue.xa, &id, q, xa_limit_32b, GFP_KERNEL);
What about moving the xa_alloc above setting 'q->xef' and calling
xe_vm_add_exec_queue?
Matt
> - if (err)
> + if (err) {
> + /*
> + * q->xef is already set, so xe_exec_queue_fini() will
> + * decrement pending_removal even without an xarray entry.
> + */
> + atomic_inc(&xef->exec_queue.pending_removal);
> goto del_hw_engine_group;
> + }
>
> args->exec_queue_id = id;
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-11-13 18:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 6:54 [PATCH] drm/xe: Account for exec queue cleanup after handle allocation fails Arvind Yadav
2026-11-13 7:02 ` ✗ CI.checkpatch: warning for " Patchwork
2026-11-13 7:04 ` ✓ CI.KUnit: success " Patchwork
2026-11-13 7:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-13 18:13 ` ✓ Xe.CI.FULL: " Patchwork
2026-11-13 18:27 ` Matthew Brost [this message]
2026-11-14 8:25 ` [PATCH] " Yadav, Arvind
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=avdWloP416vGgEgT@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=arvind.yadav@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=tejas.upadhyay@intel.com \
--cc=thomas.hellstrom@linux.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.