On Fri, 6 Mar 2026 10:58:07 +0100 Christian König <[email protected]> wrote:
> On 3/6/26 10:46, Boris Brezillon wrote: > > On Fri, 6 Mar 2026 09:10:52 +0100 > > Christian König <[email protected]> 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.
