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: <20260206122304.2820c375@fedora>
Date: Fri, 6 Feb 2026 12:23:04 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Philipp Stanner <phasta@...lbox.org>
Cc: phasta@...nel.org, Gary Guo <gary@...yguo.net>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Danilo Krummrich
 <dakr@...nel.org>, 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, 06 Feb 2026 10:32:38 +0100
Philipp Stanner <phasta@...lbox.org> wrote:

> On Thu, 2026-02-05 at 13:16 +0000, Gary Guo wrote:
> > On Thu Feb 5, 2026 at 10:16 AM GMT, Boris Brezillon wrote:  
> > > On Tue,  3 Feb 2026 09:14:01 +0100
> > > Philipp Stanner <phasta@...nel.org> wrote:
> > >   
> > > >   
> 
> […]
> 
> > > > +#[pin_data]
> > > > +pub struct DmaFence<T> {
> > > > +    /// The actual dma_fence passed to C.
> > > > +    #[pin]
> > > > +    inner: Opaque<bindings::dma_fence>,
> > > > +    /// User data.
> > > > +    #[pin]
> > > > +    data: T,  
> > > 
> > > A DmaFence is a cross-device synchronization mechanism that can (and
> > > will)
> > >   
> 
> I'm not questioning the truth behind this statement. They are designed
> to do that. But is that actually being done, currently? I recently
> found that the get_driver_name() callback intended to inform the
> consumer of a fence about who actually issued the fence is only ever
> used by i915.

It's also used by the dma-buf layer to expose info about dma-bufs
through debugfs (see dma_{fence,resv}_describe() and
dma_buf_debug_show()), meaning all GPU drivers adding their fences to
the dma_resv of an imported/exported buffer object should expect to
have their ::get_{driver,timeline}_name() implementation called.