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] [day] [month] [year] [list]

Message-ID: <7f1527d29ff1ea30d6d6ff2117e7aa547b4a7f00.camel@mailbox.org>
Date: Fri, 06 Feb 2026 14:24:01 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Danilo Krummrich <dakr@...nel.org>
Cc: phasta@...nel.org, Gary Guo <gary@...yguo.net>, Boris Brezillon
 <boris.brezillon@...labora.com>, David Airlie <airlied@...il.com>, Simona
 Vetter <simona@...ll.ch>, Alice Ryhl <aliceryhl@...gle.com>, Benno Lossin
 <lossin@...nel.org>,  Christian König
 <christian.koenig@....com>, 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 Fri, 2026-02-06 at 11:16 +0100, Danilo Krummrich wrote:
> On Fri Feb 6, 2026 at 10:32 AM CET, Philipp Stanner wrote:
> > Who needs fences from another driver?
> 
> When you get VM_BIND and EXEC IOCTLs a driver takes a list of syncobjs the
> submitted job should wait for before execution.
> 
> The fences of those syncobjs can be from anywhere, including other DRM drivers.
> 
> > I think we should go one step back here and question the general
> > design.
> > 
> > I only included data: T because it was among the early feedback that
> > this is how you do it in Rust.
> > 
> > I was never convinced that it's a good idea. Jobqueue doesn't need the
> > 'data' field. Can anyone think of anyone who would need it?
> > 
> > What kind of data would be in there? It seems a driver would store its
> > equivalent of C's
> > 
> > struct my_fence {
> >    struct dma_fence f;
> >    /* other driver data */
> > }
> > 
> > which is then accessed in C with container_of.
> 
> Your current struct is exactly this pattern:
> 
> 	struct DmaFence<T> {
> 	    inner: Opaque<bindings::dma_fence>,
> 	    ...
> 	    data: T,
> 	}
> 
> So, in Rust you can just write DmaFence<MyData> rather than,
> 
> 	struct my_dma_fence {
> 		struct dma_fence inner;
> 		struct my_data data;
> 	}
> 
> > But that data is only ever needed by that very driver.
> 
> Exactly, this is the "owned" type that is only ever used by this driver.
> 
> > They are *not* a data transfer mechanism. It seems very wrong design-
> > wise to transfer generic data T from one driver to another. That's not
> > a fence's purpose. Another primitive should be used for that.
> > 
> > If another driver could touch / consume / see / use the emitter's data:
> > T, that would grossly decouple us from the original dma_fence design.
> > It would be akin to doing a container_of to consume foreign driver
> > data.
> 
> Correct, that's why the suggestion here was to have a second type that is only
> 
> 	struct ForeignDmaFence {
> 	    inner: Opaque<bindings::dma_fence>,
> 	    ...,
> 	    /* No data. */
> 	}
> 
> i.e. it does not not provide access to the rest of the allocation, since it is
> private to the owning driver.
> 
> This type should also not have methods like signal(), since only the owner of
> the fence should be allowed to signal the fence.


So to be sure, you envision it like that:


let foreign_fence = ForeignDmaFence::new(normal_dma_fence)?;
foreign_fence.register_callback(my_consequences)?;

?

With a foreign_fence taking another reference to bindings::dma_fence I
suppose.

Which would mean that we would need to accept those  foreign fences for
jobqueue methods, too.


And what kind of fence do we imagine should

let done_fence = jq.submit_job(job)?;

be?



P.