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: <aYsyGAwy4rq-H7Hd@google.com>
Date: Tue, 10 Feb 2026 13:26:48 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boris Brezillon <boris.brezillon@...labora.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, Feb 10, 2026 at 01:49:13PM +0100, Boris Brezillon 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?

The {Must,Will}BeSignalled closure pair needs to wrap the piece of code
that ensures a specific fence is signalled. If you have code that
manages a collection of fences and invokes code for specific fences
depending on outside conditions, then that's a different matter.

After all, transfer_to_wq() has two components:
1. Logic to ensure any spawned workqueue job eventually gets to run.
2. Once the individual job runs, logic specific to the one fence ensures
   that this one fence gets signalled.
And {Must,Will}BeSignalled exists to help model part (2.). But what you
described with the IRQ callback falls into (1.) instead, which is
outside the scope of {Must,Will}BeSignalled (or at least requires more
complex APIs).

Alice