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

[Philipp Stanner <phasta@mailbox.org>]

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?

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 :)

> 
> 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.


P.