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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260209155843.725dcfe1@fedora>
Date: Mon, 9 Feb 2026 15:58:43 +0100
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Philipp Stanner <phasta@...lbox.org>
Cc: phasta@...nel.org, Danilo Krummrich <dakr@...nel.org>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Alice Ryhl
 <aliceryhl@...gle.com>, Gary Guo <gary@...yguo.net>, 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 Mon, 09 Feb 2026 09:19:46 +0100
Philipp Stanner <phasta@...lbox.org> wrote:

> On Fri, 2026-02-06 at 11:23 +0100, Danilo Krummrich wrote:
> > On Thu Feb 5, 2026 at 9:57 AM CET, Boris Brezillon wrote:  
> > > On Tue,  3 Feb 2026 09:14:01 +0100
> > > Philipp Stanner <phasta@...nel.org> wrote:
> > > Unfortunately, I don't know how to translate that in rust, but we
> > > need a way to check if any path code path does a DmaFence.signal(),
> > > go back to the entry point (for a WorkItem, that would be
> > > WorkItem::run() for instance), and make it a DmaFenceSignallingPath.
> > > Not only that, but we need to know all the deps that make it so
> > > this path can be called (if I take the WorkItem example, that would
> > > be the path that leads to the WorkItem being scheduled).  
> > 
> > I think we need a guard object for this that is not Send, just like for any
> > other lock.
> > 
> > Internally, those markers rely on lockdep, i.e. they just acquire and release a
> > "fake" lock.  
> 
> The guard object would be created through fence.begin_signalling(), wouldn't it?

It shouldn't be a (&self)-method, because at the start of a DMA
signaling path, you don't necessarily know which fence you're going to
signal (you might actually signal several of them).

> And when it drops you call dma_fence_end_signalling()?

Yep, dma_fence_end_signalling() should be called when the guard is
dropped.

> 
> How would that ensure that the driver actually marks the signalling region correctly?

Nothing, and that's a problem we have in C: you have no way of telling
which code section is going to be a DMA-signaling path. I can't think
of any way to make that safer in rust, unfortunately. The best I can
think of would be to

- Have a special DmaFenceSignalWorkItem (wrapper a WorkItem with extra
  constraints) that's designed for DMA-fence signaling, and that takes
  the DmaSignaling guard around the ::run() call.
- We would then need to ensure that any code path scheduling this work
  item is also in a DMA-signaling path by taking a ref to the
  DmaSignalingGuard. This of course doesn't guarantee that the section
  is wide enough to prevent any non-authorized operations in any path
  leading to this WorkItem scheduling, but it would at least force the
  caller to consider the problem.