From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: <intel-xe@lists.freedesktop.org>, <kernel-dev@igalia.com>,
Matthew Brost <matthew.brost@intel.com>,
Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH] drm/xe: Assign queue name in time for drm_sched_init
Date: Fri, 22 May 2026 12:10:04 -0400 [thread overview]
Message-ID: <ahB_3OV1sSfrfDwY@intel.com> (raw)
In-Reply-To: <20260522144003.12836-1-tvrtko.ursulin@igalia.com>
On Fri, May 22, 2026 at 03:40:03PM +0100, Tvrtko Ursulin wrote:
> Currently the queue name is only assigned after the drm scheduler instance
> has been created. This loses information with all logging or debug
> workqueue facilities so lets re-order things a bit so the name gets
> assigned in time.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_submit.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index afd8cc7bd231..28f3b23527e6 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -1961,6 +1961,13 @@ static int guc_exec_queue_init(struct xe_exec_queue *q)
> timeout = (q->vm && xe_vm_in_lr_mode(q->vm)) ? MAX_SCHEDULE_TIMEOUT :
> msecs_to_jiffies(q->sched_props.job_timeout_ms);
>
> + mutex_lock(&guc->submission_state.lock);
> + err = alloc_guc_id(guc, q);
> + mutex_unlock(&guc->submission_state.lock);
> + if (err)
> + goto err_free;
> + xe_exec_queue_assign_name(q, q->guc->id);
I'm afraid this might open some race conditions here.
First I wondering about simply moving the mutex to inside the alloc_guc_id
itself where the submission_state is used so it gets clear, then
I saw the FIXME message in there and wondered why could had made it
harder when it was first developed.
Then I read the Sashiko
https://sashiko.dev/#/patchset/20260522144003.12836-1-tvrtko.ursulin%40igalia.com
Perhaps the safest approach here is to use a unlocked xa_reserve to get
the id and create the name. With this you already get the GFP_NOWAIT FIXME note
fixed.
Then you keep the xa_store down later, not opening for any possible races.
2-in-1 fix...
> +
> /*
> * Use primary queue's submit_wq for all secondary queues of a
> * multi queue group. This serialization avoids any locking around
> @@ -1977,28 +1984,20 @@ static int guc_exec_queue_init(struct xe_exec_queue *q)
> timeout, guc_to_gt(guc)->ordered_wq, NULL,
> q->name, gt_to_xe(q->gt)->drm.dev);
> if (err)
> - goto err_free;
> + goto err_release_id;
>
> sched = &ge->sched;
> err = xe_sched_entity_init(&ge->entity, sched);
> if (err)
> goto err_sched;
>
> - mutex_lock(&guc->submission_state.lock);
> -
> - err = alloc_guc_id(guc, q);
> - if (err)
> - goto err_entity;
> -
> q->entity = &ge->entity;
>
> + mutex_lock(&guc->submission_state.lock);
> if (xe_guc_read_stopped(guc) || vf_recovery(guc))
> xe_sched_stop(sched);
> -
> mutex_unlock(&guc->submission_state.lock);
>
> - xe_exec_queue_assign_name(q, q->guc->id);
> -
> /*
> * Maintain secondary queues of the multi queue group in a list
> * for handling dependencies across the queues in the group.
> @@ -2021,11 +2020,10 @@ static int guc_exec_queue_init(struct xe_exec_queue *q)
>
> return 0;
>
> -err_entity:
> - mutex_unlock(&guc->submission_state.lock);
> - xe_sched_entity_fini(&ge->entity);
> err_sched:
> xe_sched_fini(&ge->sched);
> +err_release_id:
> + release_guc_id(guc, q);
> err_free:
> kfree(ge);
>
> --
> 2.54.0
>
next prev parent reply other threads:[~2026-05-22 16:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 14:40 [PATCH] drm/xe: Assign queue name in time for drm_sched_init Tvrtko Ursulin
2026-05-22 16:10 ` Rodrigo Vivi [this message]
2026-05-22 16:18 ` Tvrtko Ursulin
2026-05-22 16:45 ` ✓ CI.KUnit: success for " Patchwork
2026-05-22 17:25 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-05-23 0:28 ` ✗ Xe.CI.FULL: " 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=ahB_3OV1sSfrfDwY@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=matthew.brost@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tvrtko.ursulin@igalia.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.