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

[Alice Ryhl]

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

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

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

Alice