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
>
prev parent 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