From: Matthew Brost <matthew.brost@intel.com>
To: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: "Yadav, Arvind" <arvind.yadav@intel.com>,
<intel-xe@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/guc: Keep scheduler timeline name alive
Date: Wed, 15 Jul 2026 00:54:47 -0700 [thread overview]
Message-ID: <alc8x/nLLb+L/aFK@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <ba1420ef-26df-413a-8554-b60f470b9344@ursulin.net>
On Wed, Jul 15, 2026 at 08:49:00AM +0100, Tvrtko Ursulin wrote:
>
> On 15/07/2026 05:26, Yadav, Arvind wrote:
> >
> > On 14-07-2026 15:02, Tvrtko Ursulin wrote:
> > >
> > > On 14/07/2026 07:44, Arvind Yadav wrote:
> > > > The scheduler keeps a pointer to the timeline name, but q->name
> > > > is freed with the exec queue while scheduler fences can still
> > > > reference it.
> > > >
> > > > Store the name in struct xe_guc_exec_queue so it shares
> > > > the scheduler's RCU-deferred lifetime.
> > > >
> > > > Fixes: 6bd90e700b42 ("drm/xe: Make dma-fences compliant with the
> > > > safe access rules")
> > >
> > > Feel free to copy me if I broke something, or even fixed it
> > > incompletely. :)
> > >
> > > It is curious since I had an IGT which confirmed the fix was
> > > effective by dereferencing the timeline.
> > >
> > > At the time of the above commit:
> > >
> > > __guc_exec_queue_process_msg_cleanup
> > > __guc_exec_queue_fini
> > > guc_exec_queue_fini_async
> > > ...
> > > xe_sched_entity_fini
> > > xe_sched_fini
> > > kfree_rcu ge
> > > xe_exec_queue_fini q
> > > __xe_exec_queue_free
> > > kfree q
> > >
> > >
> > > Now:
> > >
> > > __guc_exec_queue_process_msg_cleanup
> > > __guc_exec_queue_destroy
> > > guc_exec_queue_destroy_async
> > > __guc_exec_queue_destroy_async
> > > xe_exec_queue_fini
> > > __xe_exec_queue_fini
> > > guc_exec_queue_fini
> > > ...
> > > xe_sched_entity_fini
> > > xe_sched_fini
> > > kfree_rcu ge
> > > __xe_exec_queue_free
> > > kfree q
> > >
> > > Looks functionally identical.
> > >
> > > AFAIR the problem actually was:
> > >
> > > drm_sched_fence_get_timeline_name()
> > > return (const char *)fence->sched->name;
> > >
> > > Where fence->sched is drm sched, aka "ge" from the above flow.
> > >
> > > And that has kfree_rcu in the today's code base too. So no issue
> > > with the sched pointer itself.
> > >
> > > What about sched->name ie. q->name? It is only free after the
> > > scheduler is freed, so after the RCU grace, and if scheduler itself
> > > is unreachable then sched->name is surely unreachable too.
> > >
> > > What am I missing? Could you provide some details on where and how
> > > this crashes?
> > >
> > Thanks Tvrtko,
> >
> > The gap is in the lifetime of sched->name, not fence->sched.
> > drm_sched_init() stores the name as a pointer. it does not copy it.
> > Today that pointer refers to q->name, which is embedded in struct
> > xe_exec_queue.
> >
> > The teardown order is:
> > kfree_rcu(ge) // scheduler remains valid until the RCU grace
> > period
> > kfree(q) // q->name is freed immediately
> >
> > So during the RCU grace period, fence->sched is still valid, but fence-
> > >sched->name points into the already freed q. The patch moves the name
> > storage into ge, so the scheduler and its name share the same RCU-
> > deferred lifetime.
>
> With a fresh pair of eyes, this definitely looks obviously true. But it is
> really odd KASAN did not spot this back then. It was easily spotting the
> fence->sched dereference and then with kfree_rcu it was completely happy.
> Odd so sorry for the noise.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
I seem to remember bringing this up before, but I also remember it
getting lost in the convoluted reasoning.
Tvrtko's nit aside below:
Acked-by: Matthew Brost <matthew.brost@intel.com>
>
> Just one comment below:
>
> > this issue is pointed by sashiko -: https://sashiko.dev/#/
> > patchset/20260713042530.2108459-1-arvind.yadav%40intel.com
> >
> > Regards,
> > Arvind
> >
> >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > > > Cc: Matthew Brost <matthew.brost@intel.com>
> > > > Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
> > > > ---
> > > > drivers/gpu/drm/xe/xe_guc_exec_queue_types.h | 5 +++++
> > > > drivers/gpu/drm/xe/xe_guc_submit.c | 4 +++-
> > > > 2 files changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
> > > > b/drivers/ gpu/drm/xe/xe_guc_exec_queue_types.h
> > > > index e5e53b421f29..cda14d954e57 100644
> > > > --- a/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
> > > > +++ b/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
> > > > @@ -10,6 +10,7 @@
> > > > #include <linux/workqueue.h>
> > > > #include "xe_gpu_scheduler_types.h"
> > > > +#include "xe_hw_fence_types.h"
> > > > struct dma_fence;
> > > > struct xe_exec_queue;
> > > > @@ -24,6 +25,10 @@ struct xe_guc_exec_queue {
> > > > struct rcu_head rcu;
> > > > /** @sched: GPU scheduler for this xe_exec_queue */
> > > > struct xe_gpu_scheduler sched;
> > > > + /**
> > > > + * @name: Scheduler timeline name, kept with @sched until RCU free.
>
> Strictly speaking it's not the name that is specifically kept but the whole
> struct, so maybe drop the ", kept with..." part?
>
> Regards,
>
> Tvrtko
>
> > > > + */
> > > > + char name[MAX_FENCE_NAME_LEN];
> > > > /** @entity: Scheduler entity for this xe_exec_queue */
> > > > struct xe_sched_entity entity;
> > > > /**
> > > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > b/drivers/gpu/drm/xe/ xe_guc_submit.c
> > > > index cec3bbf3a10e..8ef6eeebfaa8 100644
> > > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > > @@ -1978,6 +1978,8 @@ static int guc_exec_queue_init(struct
> > > > xe_exec_queue *q)
> > > > xe_exec_queue_assign_name(q, q->guc->id);
> > > > + strscpy(ge->name, q->name, sizeof(ge->name));
> > > > +
> > > > /*
> > > > * Use primary queue's submit_wq for all secondary queues of a
> > > > * multi queue group. This serialization avoids any locking around
> > > > @@ -1992,7 +1994,7 @@ static int guc_exec_queue_init(struct
> > > > xe_exec_queue *q)
> > > > err = xe_sched_init(&ge->sched, &drm_sched_ops, &xe_sched_ops,
> > > > submit_wq, xe_lrc_ring_size() /
> > > > MAX_JOB_SIZE_BYTES, 64,
> > > > timeout, guc_to_gt(guc)->ordered_wq, NULL,
> > > > - q->name, gt_to_xe(q->gt)->drm.dev);
> > > > + ge->name, gt_to_xe(q->gt)->drm.dev);
> > > > if (err)
> > > > goto err_release_id;
> > >
>
next prev parent reply other threads:[~2026-07-15 7:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 6:44 [PATCH] drm/xe/guc: Keep scheduler timeline name alive Arvind Yadav
2026-07-14 8:20 ` ✓ CI.KUnit: success for " Patchwork
2026-07-14 9:32 ` [PATCH] " Tvrtko Ursulin
2026-07-15 4:26 ` Yadav, Arvind
2026-07-15 7:49 ` Tvrtko Ursulin
2026-07-15 7:54 ` Matthew Brost [this message]
2026-07-15 8:09 ` Tvrtko Ursulin
2026-07-14 12:55 ` ✓ Xe.CI.FULL: success for " 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=alc8x/nLLb+L/aFK@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=arvind.yadav@intel.com \
--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 \
--cc=tursulin@ursulin.net \
/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.