All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yadav, Arvind" <arvind.yadav@intel.com>
To: Tvrtko Ursulin <tursulin@ursulin.net>, <intel-xe@lists.freedesktop.org>
Cc: <matthew.brost@intel.com>, <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 09:56:34 +0530	[thread overview]
Message-ID: <13aa91ef-452d-411d-9bb5-0ca43ea169da@intel.com> (raw)
In-Reply-To: <3f103d7b-3a58-4c3d-a4d7-e413e7b92e47@ursulin.net>


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.

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.
>> +     */
>> +    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;
>

  reply	other threads:[~2026-07-15  4:26 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 [this message]
2026-07-15  7:49     ` Tvrtko Ursulin
2026-07-15  7:54       ` Matthew Brost
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=13aa91ef-452d-411d-9bb5-0ca43ea169da@intel.com \
    --to=arvind.yadav@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --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.