linux-kernel - Re: [RFC PATCH 2/4] 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: <20260210135626.0fe9b590@fedora>
Date: Tue, 10 Feb 2026 13:56:26 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: "Christian König" <christian.koenig@....com>, Philipp
 Stanner <phasta@...lbox.org>, phasta@...nel.org, Danilo Krummrich
 <dakr@...nel.org>, David Airlie <airlied@...il.com>, Simona Vetter
 <simona@...ll.ch>, Gary Guo <gary@...yguo.net>, Benno Lossin
 <lossin@...nel.org>, Daniel Almeida <daniel.almeida@...labora.com>, Joel
 Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org
Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

On Tue, 10 Feb 2026 13:49:13 +0100
Boris Brezillon <boris.brezillon@...labora.com> wrote:

> On Tue, 10 Feb 2026 10:15:04 +0000
> Alice Ryhl <aliceryhl@...gle.com> wrote:
> 
> > /// The owner of this value must ensure that this fence is signalled.
> > struct MustBeSignalled<'fence> { ... }
> > /// Proof value indicating that the fence has either already been
> > /// signalled, or it will be. The lifetime ensures that you cannot mix
> > /// up the proof value.
> > struct WillBeSignalled<'fence> { ... }  
> 
> Sorry, I have more questions, unfortunately. Seems that
> {Must,Will}BeSignalled are targeting specific fences (at least that's
> what the doc and 'fence lifetime says), but in practice, the WorkItem
> backing the scheduler can queue 0-N jobs (0 if no jobs have their deps
> met, and N > 1 if more than one job is ready). Similarly, an IRQ
> handler can signal 0-N fences (can be that the IRQ has nothing to do we
> job completion, or, it can be that multiple jobs have completed). How
> is this MustBeSignalled object going to be instantiated in practice if
> it's done before the DmaFenceWorkItem::run() function is called?

For the scheduler WorkItem (assuming a JobQueue model), it's kinda
doable, because this is a FIFO, and we can get the first job in the
queue (and thus the fence attached to this job) quite easily, but as
soon as it's a post-execution WorkItem or IRQHandler, we never know
when entering WorkItem::run()/ThreadedHandler::handle_threaded()
which job will be completed (if any).