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: <aNfnkhXnnxqdfPYz@tardis.local>
Date: Sat, 27 Sep 2025 06:33:06 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: 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 Sat, Sep 27, 2025 at 11:01:38AM +0200, Philipp Stanner wrote:
[..]
> > > ---
> > >  rust/bindings/bindings_helper.h |   1 +
> > >  rust/helpers/dma_fence.c        |  23 ++
> > >  rust/helpers/helpers.c          |   1 +
> > >  rust/helpers/spinlock.c         |   5 +
> > >  rust/kernel/sync.rs             |   2 +
> > >  rust/kernel/sync/dma_fence.rs   | 388 ++++++++++++++++++++++++++++++++
> > 
> > I missed this part, and I don't think kernel::sync is where dma_fence
> > should be, as kernel::sync is mostly for the basic synchronization
> > between threads/irqs. dma_fence is probably better to be grouped with
> > dma-buf and other dma related primitives. Maybe in kernel::dma? Like:
> > 
> > rust/kernel/dma.rs
> > rust/kernel/dma/dma_buf.rs
> > rust/kernel/dma/dma_fence.rs
> > 
> > Thoughts? Miguel, Greg, Danilo and Lyude, any idea or suggestion?
> 
> @Christian König's opinion would be valuable, too.
> 
> I'm not super convinced of that because dma_fence has not really much
> to do with DMA. They're not very different from completions and are a
> mechanism to synchronize consumers and producers.
> 
> Actually, before f54d1867005c3 they were just called "fence" and then
> renamed to "dma_fence" because someone wanted that name.
> 

Well, dma-fence.c lives in drivers/dma-buf/, and IIUC it will only be
built in CONFIG_DMA_SHARED_BUFFER is selected. They are enough evidences
to show that dma_fence is not considered as a general fence. Of course,
the implementation of dma_fence may not be tied to any DMA
functionality, but before we make it a general fence in Rust, we need to
at least change it in C as well.

Regards,
Boqun

> 
> Anyways, I don't have strong objections and mostly care about having
> them available somewhere.
> 
> P.
> 
> > 
> > Regards,
> > Boqun
> > 
> > >  6 files changed, 420 insertions(+)
> > >  create mode 100644 rust/helpers/dma_fence.c
> > >  create mode 100644 rust/kernel/sync/dma_fence.rs
> > > 
> > [...]
>