linux-kernel - Re: [RFC WIP 2/3] rust: sync: Add dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251125115829.24e6caf7@fedora>
Date: Tue, 25 Nov 2025 11:58:29 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Philipp Stanner <phasta@...lbox.org>
Cc: phasta@...nel.org, Daniel Almeida <daniel.almeida@...labora.com>, Alice
 Ryhl <aliceryhl@...gle.com>, Danilo Krummrich <dakr@...nel.org>, Christian
 König <ckoenig.leichtzumerken@...il.com>, Tvrtko Ursulin
 <tursulin@...ulin.net>, Alexandre Courbot <acourbot@...dia.com>, Dave
 Airlie <airlied@...hat.com>, Lyude Paul <lyude@...hat.com>, Peter Colberg
 <pcolberg@...hat.com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [RFC WIP 2/3] rust: sync: Add dma_fence abstractions

On Tue, 25 Nov 2025 10:48:12 +0100
Philipp Stanner <phasta@...lbox.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).