linux-kernel - Re: [RFC PATCH] 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: <12c09de235023c99a8a864b17b2f797c7339bb7b.camel@mailbox.org>
Date: Fri, 26 Sep 2025 10:48:06 +0200
From: Philipp Stanner <phasta@...lbox.org>
To: Boqun Feng <boqun.feng@...il.com>, Philipp Stanner <phasta@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  Benno Lossin <lossin@...nel.org>, Andreas
 Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>,  Ingo Molnar <mingo@...hat.com>, Will
 Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, Nathan
 Chancellor <nathan@...nel.org>, Nick Desaulniers
 <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, Justin
 Stitt <justinstitt@...gle.com>, Sumit Semwal <sumit.semwal@...aro.org>,
 Christian König <christian.koenig@....com>, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>,  Viresh Kumar
 <viresh.kumar@...aro.org>, Asahi Lina <lina+kernel@...hilina.net>, Daniel
 Almeida <daniel.almeida@...labora.com>, Tamir Duberstein
 <tamird@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, FUJITA
 Tomonori <fujita.tomonori@...il.com>, Krishna Ketan Rai
 <prafulrai522@...il.com>, Lyude Paul <lyude@...hat.com>, Mitchell Levy
 <levymitchell0@...il.com>, linux-kernel@...r.kernel.org, 
 rust-for-linux@...r.kernel.org, llvm@...ts.linux.dev, 
 dri-devel@...ts.freedesktop.org
Subject: Re: [RFC PATCH] rust: sync: Add dma_fence abstractions

On Thu, 2025-09-18 at 15:52 +0200, Boqun Feng wrote:
> On Thu, Sep 18, 2025 at 02:30:59PM +0200, Philipp Stanner wrote:
> [...]
> > ---
> > So. ¡Hola!
> > 
> > This is a highly WIP RFC. It's obviously at many places not yet
> > conforming very well to Rust's standards.
> > 
> > Nevertheless, it has progressed enough that I want to request comments
> > from the community.
> > 
> > There are a number of TODOs in the code to which I need input.
> > 
> > Notably, it seems (half-)illegal to use a shared static reference to an
> > Atomic, which I currently use for the dma_fence unit test / docstring
> 
> The `CHECKER` static you mean? If so, it should be a `static CHECKER`
> instead of `static mut CHECKER`, also for future versions please use
> LKMM (Linux Kernel Memory Model) atomics [1] instead of Rust native
> atomics (you probably need to define `CHECKER` as `Atomic<i32>` because
> AtomicBool is not supported by LKMM and potentially sub-optimial in some
> cases).

Thanks.

Thinking about it I realized that for that example code I don't even
need atomics. So I'll drop them for now.

> 
> > test. I'm willing to rework that if someone suggests how.
> > (Still, shouldn't changing a global Atomic always be legal? It can race,
> > of course. But that's kind of the point of an atomic)
> > 
> > What I want comments on the most is the design of the callbacks. I think
> > it's a great opportunity to provide Rust drivers with rust-only
> > callbacks, so that they don't have to bother about the C functions.
> > 
> > dma_fence wise, only the most basic callbacks currently get implemented.
> > For Nova, AFAICS, we don't need much more than signalling fences and
> > registering callbacks.
> > 
> > 
> > Another, solvable, issue I'm having is designing the
> > dma_fence_begin_signallin() abstractions. There are TODOs about that in
> > the code. That should ideally be robust and not racy. So we might want
> > some sort of synchronized (locked?) way for using that abstraction.
> > 
> > 
> > Regarding the manually created spinlock of mine: I so far never need
> > that spinlock anywhere in Rust and wasn't sure what's then the best way
> > to pass a "raw" spinlock to C.
> > 
> 
> You can use `SpinLock<()>` for this purpose, no need to add new
> bindings.

The dma_fence C backend needs a spinlock pointer, given to it by the
driver (so Rust code).

How do I pass a SpinLock<()> to a C function? AFAICS SpinLock doesn't
implement as_raw(), so I'd have to implement it, wouldn't I?

Or rather, as it looks, I'd have to implement it for SpinLockBackend?


P.

> 
> [1]: https://lore.kernel.org/rust-for-linux/20250905044141.77868-1-boqun.feng@gmail.com/
> 
> Regards,
> Boqun
> 
> > 
> > So much from my side. Hope to hear from you.
> > 
> > (I've compiled and tested this with the unit test on the current -rc3)
> > 
> > Philipp
> > ---
> [...]