Re: [RFC WIP 2/3] rust: sync: Add dma_fence abstractions

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

On Tue, 25 Nov 2025 10:48:12 +0100
Philipp Stanner <phasta@mailbox.org> wrote:

> > > +impl ArcBorrow<'_, DmaFenceCtx> {
> > > +    /// Create a new fence, consuming `data`.
> > > +    ///
> > > +    /// The fence will increment the refcount of the fence context associated with this
> > > +    /// [`DmaFenceCtx`].
> > > +    pub fn new_fence<T>(
> > > +        &mut self,
> > > +        data: impl PinInit<T>,
> > > +    ) -> Result<ARef<DmaFence<T>>> {
> > > +        let fctx: Arc<DmaFenceCtx> = (*self).into();
> > > +        let seqno: u64 = fctx.get_new_fence_seqno();
> > > +
> > > +        // TODO: Should we reset seqno in case of failure?  
> > 
> > I think we should go back to the old value, yeah.  
> 
> It would be trivial to implement that (just atomic.decrement()).
> 
> The thing why the TODO even exists is that I'm a bit unsure about
> races. It seems we have to choose between either a gap in the seqnos or
> the possiblity of seqnos being out of order.
> 
> If the user / driver creates fences with >1 thread on a fence context,
> I mean.
> 
> We're pretty free in our choices, however. The shared fence-fctx
> spinlock will be removed anyways, so one could later easily replace the
> fctx atomic with a lock if that's desirable.
> 
> I can implement a seqno-decrement for now.

I don't think we need to return unused seqnos in case of failure. I
mean, we could have something like the following pseudo-code:

	atomic_cmpxchg(ctx.seqno, fence.seqno + 1, fence.seqno)

but it wouldn't cover the case where fences are not returned in the
order they were assigned, and seqnos are pretty cheap anyway (if a u64
is enough to count things in nanoseconds for hundreds of years, they are
more than enough for a fence timeline on which fences are emitted at a
way lower rate, even in case of recurring failures). The guarantee we
really care about is seqnos not going backward, because that would mess
up with the assumption that fences on a given timeline/ctx are signalled
in order (this assumption is used to coalesce fences in a
fence_array/resv IIRC).