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

[Philipp Stanner]

On Wed, 2026-09-23 at 17:35 +0200, Christian König wrote:
> 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.

I agree that it's probably quite a common use-case. I'm not sure
whether it's possible to write a convenient wrapper, though, since you
need to carry a waitqueue around.

Maybe we can put a task for it onto the DRM TODO list?

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

So you objected and it was merged anyways? With any rationale?

I think I understand now why sometimes people apply a Nacked-by, so
that it's documented that people objected against merging.

[…]

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

I try to come up with something slightly better.


P.