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

[Philipp Stanner <phasta@mailbox.org>]

On Tue, 2026-02-10 at 14:56 +0100, Christian König wrote:
> On 2/10/26 14:49, Alice Ryhl wrote:
> > On Tue, Feb 10, 2026 at 02:26:31PM +0100, Boris Brezillon wrote:
> > > On Tue, 10 Feb 2026 13:15:31 +0000
> > > Alice Ryhl <aliceryhl@google.com> wrote:
> > > 
> > > 
> > > 

[…]

> > > I mean, the timeout handler should also be considered a DMA-signalling
> > > path, and the same rules should apply to it.
> > 
> > I guess that's fair. Even with a timeout you want both to be signalling
> > path.
> > 
> > I guess more generally, if a fence is signalled by mechanism A or B,
> > whichever happens first, you have the choice between:
> 
> That doesn't happen in practice.
> 
> For each fence you only have one signaling path you need to guarantee forward progress for.
> 
> All other signaling paths are just opportunistically optimizations which *can* signal the fence, but there is no guarantee that they will.

Are you now referring to the fast-path callbacks like fence->ops-
>is_signaled()? Or are you talking about different reference holders
which might want to signal?

> 
> We used to have some exceptions to that, especially around aborting submissions, but those turned out to be a really bad idea as well.  
> 
> Thinking more about it you should probably enforce that there is only one signaling path for each fence signaling.

An idea that is floating around is to move the entire fence signaling
functionality into the dma fence context. That would have exclusive
access, and could also finally guarantee that fences must be signaled
in order.


P.