Re: [PATCH] dma-buf/dma-fence: Mark two callbacks as deprecated

["Christian König" <christian.koenig@amd.com>]

On 9/23/26 17:27, Philipp Stanner wrote:
> On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote:
>> On 9/23/26 17:03, Philipp Stanner wrote:
>>>
> 
> […]
> 
>>
>>> 	Consumers of a fence can instead notify themselves by
>>> +	 * registering a callback on the fence.
>>
>> Mhm, the wait callback is transparent to consumers it's just that implementations used it for quite a number of different hacks.
> 
> Right…
> 
> but doesn't the question then become why dma_fence_wait_timeout() even
> exists? IOW, shall we deprecate it, too?

Yes, without the wait callback it is only a wrapper to block the current thread for a dma_fence to signal using a callback.

It's still quite useful to have a common function for that I think.

> It seems to be a reimplementation of waitqueues. The driver could get
> this functionality by using a waitqueue whose event gets triggered by a
> fence callback.
> 
> dma_fence_default_wait() interacts directly with the task state with
> __XX_task() functions which looks very.. deep to me :)

That is *exactly* what I pointed out as well >10 years ago before that stuff was merged upstream :)

A wait_event based implementation would be tons of cleaner if you ask me.

>>
>> I would just drop that sentence.
>>
>>>  	 */
>>>  	signed long (*wait)(struct dma_fence *fence,
>>>  			    bool intr, signed long timeout);
>>> @@ -243,6 +249,8 @@ struct dma_fence_ops {
>>>  	/**
>>>  	 * @release:
>>>  	 *
>>> +	 * DEPRECATED!
>>> +	 *
>>>  	 * Called on destruction of fence to release additional resources.
>>>  	 * Can be called from irq context.  This callback is optional. If it is
>>>  	 * NULL, then dma_fence_free() is instead called as the default
>>> @@ -254,6 +262,12 @@ struct dma_fence_ops {
>>>  	 *
>>>  	 * If the callback is implemented the memory backing the dma_fence
>>>  	 * object must be freed RCU safe.
>>> +	 *
>>> +	 * Deprecated because it prevents the producer of a fence from
>>> +	 * unloading. No new users must be implemented. Parties with a
>>> +	 * hypothetical need for this callback can instead simply and directly
>>> +	 * perform their custom release operations one RCU grace period after
>>> +	 * they have signaled the fence.
>>
>> Yeah that is a bit problematic.
>>
>> We need my patch set to explicit signal fences instead of returning true/false from callback for that so that a backend can properly implement this.
> 
> Well, what I'm trying to say in this docu is that the driver can kick
> off custom operations that shall be performed once everyone is "done"
> with the fence after signaling it. Any driver data that might still be
> around cannot be accessed by fence consumers after signaling anymore.
> So the driver could trigger cleanup work after a graceperiod, as long
> as it does not involve kfree()-ing the fence itself.

That sounds sane to me, but I'm not sure how to phrase it cleaner either.

For now I'm ok with it, maybe somebody else has a better idea to how write this.

Thanks,
Christian.

> 
> 
> P.