AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: phasta@kernel.org, alexdeucher@gmail.com, simona.vetter@ffwll.ch,
	tursulin@ursulin.net
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/15] dma-buf: detach fence ops on signal
Date: Thu, 30 Oct 2025 16:05:38 +0100	[thread overview]
Message-ID: <45afa337-6b46-4119-abd6-f0d79a96c7fd@gmail.com> (raw)
In-Reply-To: <d4283e9220df6ce6cd9ec2ae0b011f4931f4acf5.camel@mailbox.org>

On 10/17/25 11:14, Philipp Stanner wrote:
> On Mon, 2025-10-13 at 15:48 +0200, Christian König wrote:
>> When neither a release nor a wait operation is specified it is possible
>> to let the dma_fence live on independent of the module who issued it.
>>
>> This makes it possible to unload drivers and only wait for all their
>> fences to signal.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>  drivers/dma-buf/dma-fence.c | 16 ++++++++++++----
>>  include/linux/dma-fence.h   |  4 ++--
>>  2 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 982f2b2a62c0..39f73edf3a33 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -374,6 +374,14 @@ int dma_fence_signal_timestamp_locked(struct dma_fence *fence,
>>  				      &fence->flags)))
>>  		return -EINVAL;
>>  
>> +	/*
>> +	 * When neither a release nor a wait operation is specified set the ops
>> +	 * pointer to NULL to allow the fence structure to become independent
>> +	 * who originally issued it.
>> +	 */
>> +	if (!fence->ops->release && !fence->ops->wait)
>> +		RCU_INIT_POINTER(fence->ops, NULL);
> 
> OK, so the basic idea is that still living fences can't access driver
> data or driver code anymore after the driver is unloaded. Good and
> well, nice idea. We need something like that in Rust, too.
> 
> That's based on the rule that the driver, on unload, must signal all
> the fences. Also OK.
> 
> However, how can that possibly fly by relying on the release callback
> not being implemented? How many users don't need it, and could those
> who implement release() be ported to.. sth else?

As far as I can see the only one who really needs the ->release callback for technical reasons is the DRM scheduler fence and the dma_fence_array and dma_fence_chain containers. 

For the DRM scheduler fence it is just the finished fence which needs to drop the reference to the scheduled fence because we can now be sure that nobody can cast the fence any more.

For the dma_fence_array we could actually clean up the state on signaling, but that would need some more cleanup in the framework.

For the dma_fence_chain it is a must have to avoid potential kernel stack overrun.

Apart from that all drivers should be able to cleanup their internal state necessary for signaling when they actually signal.

Regards,
Christian.

> 
> 
> P.
> 
>> +
>>  	/* Stash the cb_list before replacing it with the timestamp */
>>  	list_replace(&fence->cb_list, &cb_list);
>>  
>> @@ -513,7 +521,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)
>>  	rcu_read_lock();
>>  	ops = rcu_dereference(fence->ops);
>>  	trace_dma_fence_wait_start(fence);
>> -	if (ops->wait) {
>> +	if (ops && ops->wait) {
>>  		/*
>>  		 * Implementing the wait ops is deprecated and not supported for
>>  		 * issuer independent fences, so it is ok to use the ops outside
>> @@ -578,7 +586,7 @@ void dma_fence_release(struct kref *kref)
>>  	}
>>  
>>  	ops = rcu_dereference(fence->ops);
>> -	if (ops->release)
>> +	if (ops && ops->release)
>>  		ops->release(fence);
>>  	else
>>  		dma_fence_free(fence);
>> @@ -614,7 +622,7 @@ static bool __dma_fence_enable_signaling(struct dma_fence *fence)
>>  
>>  	rcu_read_lock();
>>  	ops = rcu_dereference(fence->ops);
>> -	if (!was_set && ops->enable_signaling) {
>> +	if (!was_set && ops && ops->enable_signaling) {
>>  		trace_dma_fence_enable_signal(fence);
>>  
>>  		if (!ops->enable_signaling(fence)) {
>> @@ -1000,7 +1008,7 @@ void dma_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
>>  
>>  	rcu_read_lock();
>>  	ops = rcu_dereference(fence->ops);
>> -	if (ops->set_deadline && !dma_fence_is_signaled(fence))
>> +	if (ops && ops->set_deadline && !dma_fence_is_signaled(fence))
>>  		ops->set_deadline(fence, deadline);
>>  	rcu_read_unlock();
>>  }
>> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
>> index 38421a0c7c5b..e1ba1d53de88 100644
>> --- a/include/linux/dma-fence.h
>> +++ b/include/linux/dma-fence.h
>> @@ -425,7 +425,7 @@ dma_fence_is_signaled_locked(struct dma_fence *fence)
>>  
>>  	rcu_read_lock();
>>  	ops = rcu_dereference(fence->ops);
>> -	if (ops->signaled && ops->signaled(fence)) {
>> +	if (ops && ops->signaled && ops->signaled(fence)) {
>>  		rcu_read_unlock();
>>  		dma_fence_signal_locked(fence);
>>  		return true;
>> @@ -461,7 +461,7 @@ dma_fence_is_signaled(struct dma_fence *fence)
>>  
>>  	rcu_read_lock();
>>  	ops = rcu_dereference(fence->ops);
>> -	if (ops->signaled && ops->signaled(fence)) {
>> +	if (ops && ops->signaled && ops->signaled(fence)) {
>>  		rcu_read_unlock();
>>  		dma_fence_signal(fence);
>>  		return true;
> 


  reply	other threads:[~2025-10-30 15:05 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 13:48 Independence for dma_fences! Christian König
2025-10-13 13:48 ` [PATCH 01/15] dma-buf: cleanup dma_fence_describe Christian König
2025-10-14 14:37   ` Tvrtko Ursulin
2025-10-23  3:45     ` Matthew Brost
2025-10-13 13:48 ` [PATCH 02/15] dma-buf: rework stub fence initialisation Christian König
2025-10-14 15:03   ` Tvrtko Ursulin
2025-10-24  7:29   ` Tvrtko Ursulin
2025-10-13 13:48 ` [PATCH 03/15] dma-buf: protected fence ops by RCU Christian König
2025-10-16 18:04   ` Tvrtko Ursulin
2025-10-31 10:35   ` Tvrtko Ursulin
2025-10-13 13:48 ` [PATCH 04/15] dma-buf: detach fence ops on signal Christian König
2025-10-16  8:56   ` Tvrtko Ursulin
2025-10-16 15:57     ` Tvrtko Ursulin
2025-10-23  4:23       ` Matthew Brost
2025-10-23  4:44         ` Matthew Brost
2025-10-30 13:52       ` Christian König
2025-10-31 10:31         ` Tvrtko Ursulin
2025-10-17  9:14   ` Philipp Stanner
2025-10-30 15:05     ` Christian König [this message]
2025-10-13 13:48 ` [PATCH 05/15] dma-buf: inline spinlock for fence protection Christian König
2025-10-16  9:26   ` Tvrtko Ursulin
2025-11-03 13:07     ` Philipp Stanner
2025-10-23 18:09   ` Matthew Brost
2025-10-30 15:14     ` Christian König
2025-10-13 13:48 ` [PATCH 06/15] dma-buf: use inline lock for the stub fence Christian König
2025-10-13 13:48 ` [PATCH 07/15] dma-buf: use inline lock for the dma-fence-array Christian König
2025-10-13 13:48 ` [PATCH 08/15] dma-buf: use inline lock for the dma-fence-chain Christian König
2025-10-13 13:48 ` [PATCH 09/15] drm/sched: use inline locks for the drm-sched-fence Christian König
2025-10-13 13:48 ` [PATCH 10/15] drm/amdgpu: fix KFD eviction fence enable_signaling path Christian König
2025-10-13 13:48 ` [PATCH 11/15] drm/amdgpu: independence for the amdgpu_fence! Christian König
2025-10-13 13:48 ` [PATCH 12/15] drm/amdgpu: independence for the amdgpu_eviction_fence! Christian König
2025-10-13 13:48 ` [PATCH 13/15] drm/amdgpu: independence for the amdgpu_vm_tlb_fence! Christian König
2025-10-13 13:48 ` [PATCH 14/15] drm/amdgpu: independence for the amdkfd_fence! Christian König
2025-10-17 22:22   ` Felix Kuehling
2025-10-30 15:07     ` Christian König
2025-10-30 20:04       ` Felix Kuehling
2025-10-13 13:48 ` [PATCH 15/15] drm/amdgpu: independence for the amdgpu_userq__fence! Christian König
2025-10-13 14:54 ` Independence for dma_fences! Philipp Stanner
2025-10-14 15:54   ` Christian König
2025-10-17  8:32     ` Philipp Stanner
2025-10-28 14:06       ` Christian König
2025-10-29 20:53         ` Matthew Brost
2025-10-30 10:59           ` Christian König
2025-10-31 17:44             ` Matthew Brost
2025-11-03 11:43               ` Christian König
2025-11-03 19:32                 ` Matthew Brost
2025-10-15  0:51 ` Dave Airlie

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=45afa337-6b46-4119-abd6-f0d79a96c7fd@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=phasta@kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox