mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Philipp Stanner" <phasta@kernel.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Yury Norov (NVIDIA)" <yury.norov@gmail.com>,
	"Asahi Lina" <lina+kernel@asahilina.net>,
	"Burak Emir" <burak.emir@gmail.com>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	"FUJITA Tomonori" <fujita.tomonori@gmail.com>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v10 1/2] rust: Add dma_fence abstractions
Date: Fri, 04 Sep 2026 17:32:55 +0200	[thread overview]
Message-ID: <DL6N387CE2AT.1LU4TDUB8QBIU@kernel.org> (raw)
In-Reply-To: <20260812072217.1971807-3-phasta@kernel.org>

On Wed Aug 12, 2026 at 9:22 AM CEST, Philipp Stanner wrote:
> Add abstractions for dma_fence in Rust.

I was about to pick this up, but ended up with too many things to tweak.

  * Fix checkpatch.pl warnings,
  * take &CStr instead of CString in FenceContext::new(),
  * change DriverFenceAllocation::ops to &'static from *const,
  * remove # Safety comment on AlwaysRefCounted::dec_ref() impl,
  * use Opaque::zeroed() instead of __GFP_ZERO,
  * use kernel vertical import style.

Here's the diff I suggest for a v11:

diff --git a/rust/helpers/dma_fence.c b/rust/helpers/dma_fence.c
index 0e08411098fa..549f6b6a7171 100644
--- a/rust/helpers/dma_fence.c
+++ b/rust/helpers/dma_fence.c
@@ -37,7 +37,8 @@ __rust_helper void rust_helper_dma_fence_lock_irqsave(struct dma_fence *f, unsig
 	dma_fence_lock_irqsave(f, *flags);
 }

-__rust_helper void rust_helper_dma_fence_unlock_irqrestore(struct dma_fence *f, unsigned long *flags)
+__rust_helper void rust_helper_dma_fence_unlock_irqrestore(struct dma_fence *f,
+							   unsigned long *flags)
 {
 	dma_fence_unlock_irqrestore(f, *flags);
 }
diff --git a/rust/kernel/dma_buf/dma_fence.rs b/rust/kernel/dma_buf/dma_fence.rs
index f22f4a07c152..d82b69f68e61 100644
--- a/rust/kernel/dma_buf/dma_fence.rs
+++ b/rust/kernel/dma_buf/dma_fence.rs
@@ -102,21 +102,23 @@ impl<'a, T: Send + Sync + FenceContextOps> FenceContext<T> {
     /// Create a new `FenceContext`.
     pub fn new<E>(
         initial_seqno: u64,
-        driver_name: CString,
-        timeline_name: CString,
+        driver_name: &CStr,
+        timeline_name: &CStr,
         data: impl PinInit<T, E>,
     ) -> impl PinInit<Self, Error>
     where
         Error: From<E>,
     {
+        let driver_name = CString::try_from(driver_name);
+        let timeline_name = CString::try_from(timeline_name);
         try_pin_init!(Self {
             // SAFETY: `dma_fence_context_alloc()` merely works on a global
             // atomic. Parameter `1` is the number of contexts we want to
             // allocate.
             nr: unsafe { bindings::dma_fence_context_alloc(1) },
             seqno: Atomic::new(initial_seqno),
-            driver_name,
-            timeline_name,
+            driver_name: driver_name?,
+            timeline_name: timeline_name?,
             nr_of_unsignaled_fences: Atomic::new(0),
             data <- data,
         })
@@ -141,7 +143,7 @@ pub fn new_fence_allocation(
             rcu_head: Default::default(),
             // `inner` remains uninitialized until a `DriverFence` takes over.
             inner: Fence {
-                inner: Opaque::uninit(),
+                inner: Opaque::zeroed(),
             },
             fctx: self,
             data,
@@ -154,7 +156,7 @@ pub fn new_fence_allocation(
         //
         // Hence, we need the manage the memory manually. It will be freed by the
         // C backend automatically once the refcount within `Fence` drops to 0.
-        let data = KBox::new(fence_data, GFP_KERNEL | __GFP_ZERO)?;
+        let data = KBox::new(fence_data, GFP_KERNEL)?;

         Ok(DriverFenceAllocation {
             data,
@@ -212,7 +214,7 @@ fn drop(self: Pin<&mut Self>) {
         // Fence ops callbacks can be called on unsignaled fences. Since these
         // callbacks can access the fence context and its data, it needs to be
         // guaranteed that a context only drops after all associated
-        // `DriverFence`s have been dropped. This is unlikely to ocurr, but would
+        // `DriverFence`s have been dropped. This is unlikely to occur, but would
         // result in silent UAF. Throw a panic to prevent that.
         //
         // TODO:
@@ -568,9 +570,6 @@ fn inc_ref(&self) {
         unsafe { bindings::dma_fence_get(self.as_raw()) }
     }

-    /// # Safety
-    ///
-    /// `ptr`must be a valid pointer to a [`DriverFence`].
     unsafe fn dec_ref(ptr: NonNull<Self>) {
         // SAFETY: `ptr` is never a NULL pointer; and when `dec_ref()` is called
         // the fence is by definition still valid.
@@ -640,15 +639,17 @@ struct DriverFenceData<'a, T: Send + Sync + FenceContextOps> {
 /// # Examples
 ///
 /// ```
-/// use kernel::dma_buf::{
-///     DriverFence,
-///     FenceContext,
-///     FenceContextOps,
-///     FenceCallback,
-///     FenceCallbackRegistration, //
+/// use kernel::{
+///     dma_buf::{
+///         DriverFence,
+///         FenceContext,
+///         FenceContextOps,
+///         FenceCallback,
+///         FenceCallbackRegistration,
+///     },
+///     str::CString,
+///     sync::aref::ARef,
 /// };
-/// use kernel::str::CString;
-/// use kernel::sync::aref::ARef;
 /// use core::fmt::Display;
 ///
 /// struct CallbackData { }
@@ -674,18 +675,16 @@ struct DriverFenceData<'a, T: Send + Sync + FenceContextOps> {
 ///
 /// let fctx_data = FenceContextData::new();
 ///
-/// let driver_name = CString::try_from_fmt(fmt!("dummy_driver"))?;
-/// let timeline_name = CString::try_from_fmt(fmt!("dummy_timeline"))?;
-///
 /// let mut fctx = KBox::pin_init(
-///     FenceContext::new(0, driver_name, timeline_name, fctx_data), GFP_KERNEL)?;
+///     FenceContext::new(0, c"dummy_driver", c"dummy_timeline", fctx_data),
+///     GFP_KERNEL,
+/// )?;
 ///
 /// struct FenceData {
 ///     data: CString,
 /// }
 ///
-/// let data = CString::try_from_fmt(fmt!("dummy_data"))?;
-/// let fence_data = FenceData { data };
+/// let fence_data = FenceData { data: c"dummy_data".try_into()? };
 ///
 /// let fence_alloc = fctx.new_fence_allocation(fence_data)?;
 /// let mut fence = fence_alloc.new_fence();
@@ -718,8 +717,8 @@ pub struct DriverFenceAllocation<'a, T: Send + Sync + FenceContextOps> {
     /// Handed over to a [`DriverFence`], or deallocated once the
     /// [`DriverFenceAllocation`] drops.
     data: KBox<DriverFenceData<'a, T>>,
-    /// Pointer for the ops for the associated [`FenceContext`]
-    ops: *const bindings::dma_fence_ops,
+    /// Reference for the ops for the associated [`FenceContext`]
+    ops: &'static bindings::dma_fence_ops,
 }

 impl<'a, T: Send + Sync + FenceContextOps> DriverFenceAllocation<'a, T> {

  reply	other threads:[~2026-09-04 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  7:22 [PATCH v10 0/2] rust / dma_buf: Add abstractions for dma_fence Philipp Stanner
2026-08-12  7:22 ` [PATCH v10 1/2] rust: Add dma_fence abstractions Philipp Stanner
2026-09-04 15:32   ` Danilo Krummrich [this message]
2026-09-04 18:53     ` Philipp Stanner
2026-09-04 19:10       ` Danilo Krummrich
2026-08-12  7:22 ` [PATCH v10 2/2] MAINTAINERS: Add entry for Rust dma-buf Philipp Stanner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DL6N387CE2AT.1LU4TDUB8QBIU@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=burak.emir@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=joelagnelf@nvidia.com \
    --cc=lina+kernel@asahilina.net \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=phasta@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®