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: <29712ecf50a8dbd6ec13865ab4313a745ea16c14.camel@mailbox.org>
Date: Tue, 10 Feb 2026 10:06:19 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Alice Ryhl <aliceryhl@...gle.com>, Christian König
	 <christian.koenig@....com>
Cc: Boris Brezillon <boris.brezillon@...labora.com>, phasta@...nel.org, 
 Danilo Krummrich <dakr@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Gary Guo <gary@...yguo.net>, Benno Lossin
 <lossin@...nel.org>,  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 Tue, 2026-02-10 at 08:38 +0000, Alice Ryhl wrote:
> On Tue, Feb 10, 2026 at 09:16:34AM +0100, Christian König wrote:
> > 
> > 
> > On the C side I have a patch set which does something very similar.
> > 
> > It's basically a WARN_ON_ONCE() which triggers as soon as you try to
> > signal a DMA fence from an IOCTL, or more specific process context.
> > 
> > Signaling a DMA fence from interrupt context, a work item or kernel
> > thread is still allowed, there is just the hole that you can schedule
> > a work item from process context as well.
> > 
> > The major problem with that patch set is that we have tons of very
> > hacky signaling paths in drivers already because we initially didn't
> > knew how much trouble getting this wrong causes.
> > 
> > I'm strongly in favor of getting this right for the rust side from the
> > beginning and enforcing strict rules for every code trying to
> > implement a DMA fence.
> 
> Hmm. Could you say a bit more about what the rules are? I just re-read
> the comments in dma-fence.c, but I have some questions.

The rules need to be written down. Elaborately and in detail, once and
for all.

We're having those discussions about the mysterious "dma fence rules"
for years, but no one has ever seen them, despite knowing that they
exist.

They seem to live only in the heads of a small number of GPU developers
who figured out through long years of experience what works and what
doesn't.

There are reasons why the state writes the laws on paper somewhere. So
that you can read them and have a source of authority..

That would end much of our endless misunderstandings and repetitive
discussions.


P.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ