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: <bb57b6837aa8044e679dad5f2589c2e0ba84c221.camel@mailbox.org>
Date: Mon, 09 Feb 2026 09:19:46 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Danilo Krummrich <dakr@...nel.org>, Boris Brezillon
	 <boris.brezillon@...labora.com>
Cc: Philipp Stanner <phasta@...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 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?
And when it drops you call dma_fence_end_signalling()?

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


P.