Message-ID: <20260203081403.68733-2-phasta@kernel.org>
Date: Tue,  3 Feb 2026 09:13:59 +0100
From: Philipp Stanner <phasta@...nel.org>
To: David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>,
	Danilo Krummrich <dakr@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Gary Guo <gary@...yguo.net>,
	Benno Lossin <lossin@...nel.org>,
	Christian König <christian.koenig@....com>,
	Boris Brezillon <boris.brezillon@...labora.com>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Joel Fernandes <joelagnelf@...dia.com>
Cc: linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	rust-for-linux@...r.kernel.org,
	Philipp Stanner <phasta@...nel.org>
Subject: [RFC PATCH 0/4] Add dma_fence abstractions and DRM Jobqueue

This series is a followup to my WIP RFC [1]. I will not send out
separate DmaFence series's anymore, because the DmaFence only makes
sense with a user, and the first user for now is Jobqueue.

Changes since the WIP RFC:
  - Complete a first working prototype for DRM Jobqueue, without timeout
    handling, and with some work to do for clean teardown.
  - Write test code for DRM Jobqueue.
  - Add abstraction for dma_fence_is_signaled() to DmaFence, since this
    is needed for the testing code.

I am happy to be able to announce that I can now provide the community
with a first operational prototype for DRM Jobqueue. I have tested it
with the code you can see in patch №4 and trust it enough to share it
with you.

This is an RFC, intended to show the rough design and to provide folks
like Tyr with something they can give some early testing.

Note that, unfortunately, I did not yet have time to take more detailed
code feedback about things like Deref into account, given by Daniel and
Boqun. Also, I still need to improve things like naming and move the
DmaFence code to the appropriate place (dma-buf).

That's all going to be done over the next weeks.

Most notably, I intend to rework the DmaFence implementation. On one
side, to implement the given feedback and make it more convenient to
use.

On the other side, Christian König is currently reworking the C
dma_fence implementation [2]. Thereby, he is trying to solve the exact same
issue that we have solved so far with the ArcBorrow for dma_fence context:
that dma_fences can outlive their fence context, thereby causing UAF.

Once that problem got solved on the C side, this will allow us for
significantly simplifying Rust DmaFence.

Note that there is still more work to do to ensure maximum robustness of
the Rust API against driver API abuse and misuse. Notably:

1. We will probably want to have Jobqueue::submit_job() return a
   DmaFence wrapper which cannot be signaled by anyone except the
   jobqueue itself. So that users can only register their own events on
   that fence. The reason is that we have already observed that with drm_sched,
   we do have drivers who signal the scheduler's internal fences.
2. Jobqueue itself still needs some more work to be resistant against
   callback-code UAF bugs (not data UAF) in case a jobqueue drops before the last
   fence and the jobqueue code (module) is unloaded.
3. There is a problem with propagating an allocation error when creating
   the jobqueue's submit WorkItem. See the corresponding TODO and the
   code, and please participate in the discussion. That's currently the
   biggest remaining design challenge.
4. We would now finally have the chance to enforce the mysterious,
   mythological "dma_fence rules" ;)
   For now my ideas regarding this would be to implement it in a way so
   that fences can only be signaled through their fence_context, like
   so:
   fctx.signal_up_to_sequence_number(50); // signals all unsignaled fences up to number 50
   So for the first time, we could actually enforce that fences must be
   signaled by increasing sequence number.


So you see, there is still a lot to do and a lot to discuss – but we're
now finally heading somewhere.


Cheers,
P.

[1] https://lore.kernel.org/rust-for-linux/20251118132520.266179-2-phasta@kernel.org/
[2] https://lore.kernel.org/dri-devel/20260120105655.7134-1-christian.koenig@amd.com/

Philipp Stanner (4):
  rust: list: Add unsafe for container_of
  rust: sync: Add dma_fence abstractions
  rust/drm: Add DRM Jobqueue
  samples: rust: Add jobqueue tester

 rust/bindings/bindings_helper.h        |   1 +
 rust/helpers/dma_fence.c               |  28 +
 rust/helpers/helpers.c                 |   1 +
 rust/helpers/spinlock.c                |   5 +
 rust/kernel/drm/jq.rs                  | 680 +++++++++++++++++++++++++
 rust/kernel/drm/mod.rs                 |   2 +
 rust/kernel/list/impl_list_item_mod.rs |  12 +-
 rust/kernel/sync.rs                    |   2 +
 rust/kernel/sync/dma_fence.rs          | 396 ++++++++++++++
 samples/rust/Kconfig                   |  11 +
 samples/rust/Makefile                  |   1 +
 samples/rust/rust_jobqueue_tester.rs   | 180 +++++++
 12 files changed, 1313 insertions(+), 6 deletions(-)
 create mode 100644 rust/helpers/dma_fence.c
 create mode 100644 rust/kernel/drm/jq.rs
 create mode 100644 rust/kernel/sync/dma_fence.rs
 create mode 100644 samples/rust/rust_jobqueue_tester.rs

-- 
2.49.0

Powered by blists - more mailing lists