Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: dri-devel@lists.freedesktop.org,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Gustavo Padovan" <gustavo@padovan.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	amd-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, kernel-dev@igalia.com
Subject: Re: [RFC v2 13/13] drm/xe: Make dma-fences compliant with the safe access rules
Date: Mon, 12 May 2025 07:11:42 -0700	[thread overview]
Message-ID: <aCIBnh6JS/JuZOcM@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20250509153352.7187-14-tvrtko.ursulin@igalia.com>

On Fri, May 09, 2025 at 04:33:52PM +0100, Tvrtko Ursulin wrote:
> Xe can free some of the data pointed to by the dma-fences it exports. Most
> notably the timeline name can get freed if userspace closes the associated
> submit queue. At the same time the fence could have been exported to a
> third party (for example a sync_fence fd) which will then cause an use-
> after-free on subsequent access.
> 
> To make this safe we need to make the driver compliant with the newly
> documented dma-fence rules. Driver has to ensure a RCU grace period
> between signalling a fence and freeing any data pointed to by said fence.
> 
> For the timeline name we simply make the queue be freed via kfree_rcu and
> for the shared lock associated with multiple queues we add a RCU grace
> period before freeing the per GT structure holding the lock.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>

This makes sense in the context of the series (e.g. assuming patch #9 lands).

With that:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> ---
>  drivers/gpu/drm/xe/xe_guc_exec_queue_types.h | 2 ++
>  drivers/gpu/drm/xe/xe_guc_submit.c           | 7 ++++++-
>  drivers/gpu/drm/xe/xe_hw_fence.c             | 3 +++
>  3 files changed, 11 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 4c39f01e4f52..a3f421e2adc0 100644
> --- a/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
> +++ b/drivers/gpu/drm/xe/xe_guc_exec_queue_types.h
> @@ -20,6 +20,8 @@ struct xe_exec_queue;
>  struct xe_guc_exec_queue {
>  	/** @q: Backpointer to parent xe_exec_queue */
>  	struct xe_exec_queue *q;
> +	/** @rcu: For safe freeing of exported dma fences */
> +	struct rcu_head rcu;
>  	/** @sched: GPU scheduler for this xe_exec_queue */
>  	struct xe_gpu_scheduler sched;
>  	/** @entity: Scheduler entity for this xe_exec_queue */
> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> index 369be36f7dc5..cda837ff0118 100644
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@ -1274,7 +1274,11 @@ static void __guc_exec_queue_fini_async(struct work_struct *w)
>  	xe_sched_entity_fini(&ge->entity);
>  	xe_sched_fini(&ge->sched);
>  
> -	kfree(ge);
> +	/*
> +	 * RCU free due sched being exported via DRM scheduler fences
> +	 * (timeline name).
> +	 */
> +	kfree_rcu(ge, rcu);
>  	xe_exec_queue_fini(q);
>  	xe_pm_runtime_put(guc_to_xe(guc));
>  }
> @@ -1457,6 +1461,7 @@ static int guc_exec_queue_init(struct xe_exec_queue *q)
>  
>  	q->guc = ge;
>  	ge->q = q;
> +	init_rcu_head(&ge->rcu);
>  	init_waitqueue_head(&ge->suspend_wait);
>  
>  	for (i = 0; i < MAX_STATIC_MSG_TYPE; ++i)
> diff --git a/drivers/gpu/drm/xe/xe_hw_fence.c b/drivers/gpu/drm/xe/xe_hw_fence.c
> index 03eb8c6d1616..b2a0c46dfcd4 100644
> --- a/drivers/gpu/drm/xe/xe_hw_fence.c
> +++ b/drivers/gpu/drm/xe/xe_hw_fence.c
> @@ -100,6 +100,9 @@ void xe_hw_fence_irq_finish(struct xe_hw_fence_irq *irq)
>  		spin_unlock_irqrestore(&irq->lock, flags);
>  		dma_fence_end_signalling(tmp);
>  	}
> +
> +	/* Safe release of the irq->lock used in dma_fence_init. */
> +	synchronize_rcu();
>  }
>  
>  void xe_hw_fence_irq_run(struct xe_hw_fence_irq *irq)
> -- 
> 2.48.0
> 

      reply	other threads:[~2025-05-12 14:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09 15:33 [RFC v2 00/13] Some (drm_sched_|dma_)fence lifetime issues Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 01/13] drm/i915: Use provided dma_fence_is_chain Tvrtko Ursulin
2025-05-09 15:47   ` Matthew Brost
2025-05-12  8:05     ` Christian König
2025-05-12  8:11       ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 02/13] dma-fence: Change signature of __dma_fence_is_later Tvrtko Ursulin
2025-05-12  8:13   ` Christian König
2025-05-09 15:33 ` [RFC v2 03/13] dma-fence: Use a flag for 64-bit seqnos Tvrtko Ursulin
2025-05-12  8:12   ` Tvrtko Ursulin
2025-05-12  8:17   ` Christian König
2025-05-12  9:20     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 04/13] dma-fence: Move array and chain checks to flags Tvrtko Ursulin
2025-05-12  8:19   ` Christian König
2025-05-12  9:14     ` Tvrtko Ursulin
2025-05-12 17:57       ` Christian König
2025-05-09 15:33 ` [RFC v2 05/13] dma-fence: Add helpers for accessing driver and timeline name Tvrtko Ursulin
2025-05-12  8:20   ` Christian König
2025-05-09 15:33 ` [RFC v2 06/13] dma-fence: Use driver and timeline name helpers internally Tvrtko Ursulin
2025-05-12  8:22   ` Christian König
2025-05-12  9:05     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 07/13] sync_file: Use dma-fence driver and timeline name helpers Tvrtko Ursulin
2025-05-12  8:25   ` Christian König
2025-05-09 15:33 ` [RFC v2 08/13] drm/amdgpu: " Tvrtko Ursulin
2025-05-12  8:27   ` Christian König
2025-05-12  9:07     ` Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 09/13] drm/i915: " Tvrtko Ursulin
2025-05-12  8:28   ` Christian König
2025-05-09 15:33 ` [RFC v2 10/13] dma-fence: Add safe access helpers and document the rules Tvrtko Ursulin
2025-05-13 14:16   ` Rob Clark
2025-05-14 10:01     ` Tvrtko Ursulin
2025-05-14 13:57       ` Rob Clark
2025-05-14 14:58         ` Tvrtko Ursulin
2025-05-14 15:38           ` Rob Clark
2025-05-09 15:33 ` [RFC v2 11/13] sync_file: Protect access to driver and timeline name Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 12/13] drm/i915: " Tvrtko Ursulin
2025-05-09 15:33 ` [RFC v2 13/13] drm/xe: Make dma-fences compliant with the safe access rules Tvrtko Ursulin
2025-05-12 14:11   ` Matthew Brost [this message]

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=aCIBnh6JS/JuZOcM@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sumit.semwal@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox