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

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

On Mon, 09 Feb 2026 09:19:46 +0100
Philipp Stanner <phasta@mailbox.org> wrote:

> On Fri, 2026-02-06 at 11:23 +0100, Danilo Krummrich wrote:
> > On Thu Feb 5, 2026 at 9:57 AM CET, Boris Brezillon wrote:  
> > > On Tue,  3 Feb 2026 09:14:01 +0100
> > > Philipp Stanner <phasta@kernel.org> wrote:
> > > Unfortunately, I don't know how to translate that in rust, but we
> > > need a way to check if any path code path does a DmaFence.signal(),
> > > go back to the entry point (for a WorkItem, that would be
> > > WorkItem::run() for instance), and make it a DmaFenceSignallingPath.
> > > Not only that, but we need to know all the deps that make it so
> > > this path can be called (if I take the WorkItem example, that would
> > > be the path that leads to the WorkItem being scheduled).  
> > 
> > I think we need a guard object for this that is not Send, just like for any
> > other lock.
> > 
> > Internally, those markers rely on lockdep, i.e. they just acquire and release a
> > "fake" lock.  
> 
> The guard object would be created through fence.begin_signalling(), wouldn't it?

It shouldn't be a (&self)-method, because at the start of a DMA
signaling path, you don't necessarily know which fence you're going to
signal (you might actually signal several of them).

> And when it drops you call dma_fence_end_signalling()?

Yep, dma_fence_end_signalling() should be called when the guard is
dropped.

> 
> How would that ensure that the driver actually marks the signalling region correctly?

Nothing, and that's a problem we have in C: you have no way of telling
which code section is going to be a DMA-signaling path. I can't think
of any way to make that safer in rust, unfortunately. The best I can
think of would be to

- Have a special DmaFenceSignalWorkItem (wrapper a WorkItem with extra
  constraints) that's designed for DMA-fence signaling, and that takes
  the DmaSignaling guard around the ::run() call.
- We would then need to ensure that any code path scheduling this work
  item is also in a DMA-signaling path by taking a ref to the
  DmaSignalingGuard. This of course doesn't guarantee that the section
  is wide enough to prevent any non-authorized operations in any path
  leading to this WorkItem scheduling, but it would at least force the
  caller to consider the problem.