Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

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

On Tue, 10 Feb 2026 13:15:31 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> On Tue, Feb 10, 2026 at 01:36:17PM +0100, Boris Brezillon wrote:
> > On Tue, 10 Feb 2026 10:15:04 +0000
> > Alice Ryhl <aliceryhl@google.com> wrote:
> >   
> > > impl MustBeSignalled<'_> {
> > >     /// Drivers generally should not use this one.
> > >     fn i_promise_it_will_be_signalled(self) -> WillBeSignalled { ... }
> > > 
> > >     /// One way to ensure the fence has been signalled is to signal it.
> > >     fn signal_fence(self) -> WillBeSignalled {
> > >         self.fence.signal();
> > >         self.i_promise_it_will_be_signalled()
> > >     }
> > > 
> > >     /// Another way to ensure the fence will be signalled is to spawn a
> > >     /// workqueue item that promises to signal it.
> > >     fn transfer_to_wq(
> > >         self,
> > >         wq: &Workqueue,
> > >         item: impl DmaFenceWorkItem,
> > >     ) -> WillBeSignalled {
> > >         // briefly obtain the lock class of the wq to indicate to
> > >         // lockdep that the signalling path "blocks" on arbitrary jobs
> > >         // from this wq completing
> > >         bindings::lock_acquire(&wq->key);
> > >         bindings::lock_release(&wq->key);
> > > 
> > >         // enqueue the job
> > >         wq.enqueue(item, wq);
> > > 
> > >         // The signature of DmaFenceWorkItem::run() promises to arrange
> > >         // for it to be signalled.
> > >         self.i_promise_it_will_be_signalled()
> > >     }  
> > 
> > I guess what's still missing is some sort of `transfer_to_hw()`
> > function and way to flag the IRQ handler taking over the fence
> > signaling token.  
> 
> Yes, transfer to hardware needs to be another piece of logic similar to
> transfer to wq. And I imagine there are many ways such a transfer to
> hardware could work.
> 
> Unless you have a timeout on it, in which case the WillBeSignalled is
> satisfied by the fact you have a timeout alone, and the signalling that
> happens from the irq is just an opportunistic signal from outside the
> dma fence signalling critical path.

Yes and no. If it deadlocks in the completion WorkItem because of
allocations (or any of the forbidden use cases), I think we want to
catch that, because that's a sign fences are likely to end up with
timeouts when they should have otherwise been signaled properly.

> 
> From dma-fence.c:
> 
>  * * The only exception are fast paths and opportunistic signalling code, which
>  *   calls dma_fence_signal() purely as an optimization, but is not required to
>  *   guarantee completion of a &dma_fence. The usual example is a wait IOCTL
>  *   which calls dma_fence_signal(), while the mandatory completion path goes
>  *   through a hardware interrupt and possible job completion worker.

In this example, the fast-signaling path is not in the IRQ handler or
the job completion work item, it's directly in the IOCTL().
Unfortuantely I don't know exactly what would cause dma_fence_signal()
to be called opportunistically in that case, because that's not part of
the description :D. I can tell you there's no such thing in panthor.

> 
> Well ... unless triggering timeouts can block on GFP_KERNEL
> allocations...

I mean, the timeout handler should also be considered a DMA-signalling
path, and the same rules should apply to it.