Re: dma_fence: force users to take the lock manually

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 6 Mar 2026 10:58:07 +0100
Christian König <christian.koenig@amd.com> wrote:

> On 3/6/26 10:46, Boris Brezillon wrote:
> > On Fri, 6 Mar 2026 09:10:52 +0100
> > Christian König <christian.koenig@amd.com> wrote:  
> >> Well as I wrote above you either have super reliable locking in your signaling path or you will need that for error handling.  
> > 
> > Not really. With rust's ownership model, you can make it so only one
> > thread gets to own the DriverFence (the signal-able fence object), and
> > the DriverFence::signal() method consumes this object. This implies
> > that only one path gets to signal the DriverFence, and after that it
> > vanishes, so no one else can signal it anymore. Just to clarify, by
> > vanishes, I mean that the signal-able view disappears, but the
> > observable object (Fence) can stay around, so it can be monitored (and
> > only monitored) by others. With this model, it doesn't matter that
> > _set_error() is set under a dma_fence locked section or not, because
> > the concurrency is addressed at a higher level.  
> 
> That whole approach won't work. You have at least the IRQ handler which signals completion and the timeout handler which signals completion with an error.

From a pure rust standpoint, and assuming both path (IRQ handler and
timeout handler) are written in rust, the compiler won't let you signal
concurrently if we design the thing properly, that's what I'm trying to
say. Just to be clear, it doesn't mean you can't have one worker (in a
workqueue context) that can signal a fence and an IRQ handler that can
signal the same fence. It just means that rust won't let you do that
unless you have proper locking in place, and rust will also guarantee
you won't be able to signal a fence that has already been signaled,
because as soon as it's signaled, the signal-able fence should be
consumed.


> 
> We have documented that this handling is mandatory for DMA-fences since so many driver implementations got it wrong.

Again, I'm just talking about the rust implementation we're aiming for.
If you start mixing C and rust in the same driver, you're back to the
original problem you described.

> 
> That's why Philips patch set removed the return value from dma_fence_signal().

I don't mind that. Just saying that's hopefully a non-issue in the rust
abstraction.