public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH v18 0/4] Rust bindings for gem shmem
@ 2026-06-04 19:24 Lyude Paul
  2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
                   ` (4 more replies)
  0 siblings, 5 replies; 14+ messages in thread
From: Lyude Paul @ 2026-06-04 19:24 UTC (permalink / raw)
  To: dri-devel, rust-for-linux, nouveau
  Cc: Alexandre Courbot, Gary Guo, Christian König, driver-core,
	Miguel Ojeda, Maarten Lankhorst, Alice Ryhl, Simona Vetter,
	linux-kernel, Sumit Semwal, linux-media, Rafael J . Wysocki,
	Thomas Zimmermann, Maxime Ripard, David Airlie, Benno Lossin,
	linaro-mm-sig, Danilo Krummrich, Mukesh Kumar Chaurasiya,
	Asahi Lina, Daniel Almeida, Lyude Paul, Greg Kroah-Hartman

Most of this patch series has already been pushed upstream, this is just
the second half of the patch series that has not been pushed yet + some
additional changes which were required to implement changes requested by
the mailing list. This patch series is originally from Asahi, previously
posted by Daniel Almeida.

The previous version of the patch series can be found here:

	https://patchwork.freedesktop.org/series/164580/

Branch with patches applied available here:

	https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem

This patch series applies on top of drm-rust-next

Patch-series wide changes since V15:
* Fix some major rebasing errors I somehow didn't notice :(
* Drop the dependency on LazyInit, use the trick that Alice suggested
  instead.
* Fix dependency ordering so that Tyr can get the vmap stuff first
  without the other bits.
Patch-series wide changes since V16:
* Fix ordering one more time (SetOnce::reset() doesn't need to come
  before adding vmap functions)
* Rebase against the latest DeviceContext changes from me that got
  pushed.

Lyude Paul (4):
  rust: drm: gem: shmem: Add DmaResvGuard helper
  rust: drm: gem: shmem: Add vmap functions
  rust: faux: Allow retrieving a bound Device
  rust: drm: gem: Introduce shmem::Object::sg_table()

 rust/kernel/drm/gem/shmem.rs | 511 ++++++++++++++++++++++++++++++++++-
 rust/kernel/faux.rs          |  16 +-
 2 files changed, 512 insertions(+), 15 deletions(-)


base-commit: fea3a2dd7d3fc1936211ced5f84420e610435730
-- 
2.54.0


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper
  2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
@ 2026-06-04 19:24 ` Lyude Paul
  2026-06-04 19:39   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  2026-06-04 19:24 ` [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions Lyude Paul
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 14+ messages in thread
From: Lyude Paul @ 2026-06-04 19:24 UTC (permalink / raw)
  To: dri-devel, rust-for-linux, nouveau
  Cc: Alexandre Courbot, Gary Guo, Christian König, driver-core,
	Miguel Ojeda, Maarten Lankhorst, Alice Ryhl, Simona Vetter,
	linux-kernel, Sumit Semwal, linux-media, Rafael J . Wysocki,
	Thomas Zimmermann, Maxime Ripard, David Airlie, Benno Lossin,
	linaro-mm-sig, Danilo Krummrich, Mukesh Kumar Chaurasiya,
	Asahi Lina, Daniel Almeida, Lyude Paul, Greg Kroah-Hartman

Just a temporary holdover to make locking/unlocking the dma_resv lock much
easier.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Co-authored-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

---
V17:
* Fix format of commit message title

 rust/kernel/drm/gem/shmem.rs | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
index 084b798ce795b..650c34dd8b7a4 100644
--- a/rust/kernel/drm/gem/shmem.rs
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -30,7 +30,10 @@
         Deref,
         DerefMut, //
     },
-    ptr::NonNull, //
+    ptr::{
+        self,
+        NonNull, //
+    },
 };
 use gem::{
     BaseObjectPrivate,
@@ -244,3 +247,29 @@ impl<T: DriverObject, C: DeviceContext> driver::AllocImpl for Object<T, C> {
         dumb_map_offset: None,
     };
 }
+
+/// Private helper-type for holding the `dma_resv` object for a GEM shmem object.
+///
+/// When this is dropped, the `dma_resv` lock is dropped as well.
+///
+// TODO: This should be replace with a WwMutex equivalent once we have such bindings in the kernel.
+struct DmaResvGuard<'a, T: DriverObject, C: DeviceContext = Registered>(&'a Object<T, C>);
+
+impl<'a, T: DriverObject, C: DeviceContext> DmaResvGuard<'a, T, C> {
+    #[inline(always)]
+    #[expect(unused)]
+    fn new(obj: &'a Object<T, C>) -> Self {
+        // SAFETY: This lock is initialized throughout the lifetime of `object`.
+        unsafe { bindings::dma_resv_lock(obj.raw_dma_resv(), ptr::null_mut()) };
+
+        Self(obj)
+    }
+}
+
+impl<'a, T: DriverObject, C: DeviceContext> Drop for DmaResvGuard<'a, T, C> {
+    #[inline(always)]
+    fn drop(&mut self) {
+        // SAFETY: We are releasing the lock grabbed during the creation of this object.
+        unsafe { bindings::dma_resv_unlock(self.0.raw_dma_resv()) };
+    }
+}
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions
  2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
  2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
@ 2026-06-04 19:24 ` Lyude Paul
  2026-06-04 19:41   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  2026-06-04 19:24 ` [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device Lyude Paul
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 14+ messages in thread
From: Lyude Paul @ 2026-06-04 19:24 UTC (permalink / raw)
  To: dri-devel, rust-for-linux, nouveau
  Cc: Alexandre Courbot, Gary Guo, Christian König, driver-core,
	Miguel Ojeda, Maarten Lankhorst, Alice Ryhl, Simona Vetter,
	linux-kernel, Sumit Semwal, linux-media, Rafael J . Wysocki,
	Thomas Zimmermann, Maxime Ripard, David Airlie, Benno Lossin,
	linaro-mm-sig, Danilo Krummrich, Mukesh Kumar Chaurasiya,
	Asahi Lina, Daniel Almeida, Lyude Paul, Greg Kroah-Hartman

One of the more obvious use cases for gem shmem objects is the ability to
create mappings into their contents. So, let's hook this up in our rust
bindings.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---
V7:
* Switch over to the new iosys map bindings that use the Io trait
V8:
* Get rid of iosys_map bindings for now, only support non-iomem types
* s/as_shmem()/as_raw_shmem()
V9:
* Get rid of some outdated comments I missed
* Add missing SIZE check to raw_vmap()
* Add a proper unit test that ensures that we actually validate SIZE at
  compile-time.
  Turns out it takes only 34 lines to make a boilerplate DRM driver for a
  kunit test :)
* Add unit tests
* Add some missing #[inline]s
V10:
* Correct issue with iomem error path
  We previously called raw_vunmap() if we got an iomem allocation, but
  raw_vunmap() was written such that it assumed all allocations were sysmem
  allocations. Fix this by just making raw_vunmap() accept a iosys_map.
V11:
* Use Alexandre's clever solution to remove the macros we were using for
  maintaining two different VMap types.
* Change the order of items in Object<T> to ensure that sgt_res is always
  dropped before obj.
* Fix typo in Object.raw_vmap()
* s/raw_vmap()/make_vmap()/
  Deduplicate code a bit more as well by using more generics here
V15:
* Add these patches back
* We only have one VMap type now!
* Use ObjectConfig::default() in unit tests since we unbroke it.
V16:
* Fix huge rebase error I made and did not notice that squashed 1.5 patches
  together that were definitely not supposed to be squashed
* Update old commit message
V17:
* Rebase
* Fix format of commit message title

 rust/kernel/drm/gem/shmem.rs | 312 ++++++++++++++++++++++++++++++++++-
 1 file changed, 311 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
index 650c34dd8b7a4..1f05a5bc5fe66 100644
--- a/rust/kernel/drm/gem/shmem.rs
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -20,12 +20,19 @@
         Registered, //
     },
     error::to_result,
+    io::{
+        Io,
+        IoCapable,
+        IoKnownSize, //
+    },
     prelude::*,
     sync::aref::ARef,
     types::Opaque, //
 };
 use core::{
+    ffi::c_void,
     marker::PhantomData,
+    mem::MaybeUninit, //
     ops::{
         Deref,
         DerefMut, //
@@ -36,6 +43,7 @@
     },
 };
 use gem::{
+    BaseObject,
     BaseObjectPrivate,
     DriverObject,
     IntoGEMObject, //
@@ -197,6 +205,80 @@ extern "C" fn free_callback(obj: *mut bindings::drm_gem_object) {
         // SAFETY: We're recovering the Kbox<> we created in gem_create_object()
         let _ = unsafe { KBox::from_raw(this) };
     }
+
+    /// Attempt to create a vmap from the gem object, and confirm the size of said vmap.
+    fn make_vmap<'a, R, const SIZE: usize>(&'a self) -> Result<VMap<T, R, C, SIZE>>
+    where
+        R: Deref<Target = Self> + From<&'a Self>,
+    {
+        // INVARIANT: We check here that the gem object is at least as large as `SIZE`.
+        if self.size() < SIZE {
+            return Err(ENOSPC);
+        }
+
+        let mut map: MaybeUninit<bindings::iosys_map> = MaybeUninit::uninit();
+        let guard = DmaResvGuard::new(self);
+
+        // SAFETY: drm_gem_shmem_vmap can be called with the DMA reservation lock held
+        to_result(unsafe {
+            bindings::drm_gem_shmem_vmap_locked(self.as_raw_shmem(), map.as_mut_ptr())
+        })?;
+
+        // Drop the guard explicitly here, since we may need to call raw_vunmap() (which re-acquires
+        // the lock).
+        drop(guard);
+
+        // SAFETY: The call to drm_gem_shmem_vmap_locked succeeded above, so we are guaranteed that
+        // map is properly initialized.
+        let map = unsafe { map.assume_init() };
+
+        // XXX: We don't currently support iomem allocations
+        if map.is_iomem {
+            // SAFETY:
+            // - The vmap operation above succeeded, guaranteeing that `map` points to a valid
+            //   memory mapping.
+            // - We checked that this is an iomem allocation, making it safe to read vaddr_iomem
+            unsafe { self.raw_vunmap(map) };
+
+            Err(ENOTSUPP)
+        } else {
+            Ok(VMap {
+                // SAFETY: We checked that this is not an iomem allocation, making it safe to read
+                // vaddr
+                addr: unsafe { map.__bindgen_anon_1.vaddr },
+                owner: self.into(),
+            })
+        }
+    }
+
+    /// Unmap a vmap from the gem object.
+    ///
+    /// # Safety
+    ///
+    /// - The caller promises that `map` is a valid vmap on this gem object.
+    /// - The caller promises that the memory pointed to by map will no longer be accesed through
+    ///   this instance.
+    unsafe fn raw_vunmap(&self, mut map: bindings::iosys_map) {
+        let _guard = DmaResvGuard::new(self);
+
+        // SAFETY:
+        // - This function is safe to call with the DMA reservation lock held.
+        // - Our `ARef` is proof that the underlying gem object here is initialized and thus safe to
+        //   dereference.
+        unsafe { bindings::drm_gem_shmem_vunmap_locked(self.as_raw_shmem(), &mut map) };
+    }
+
+    /// Creates and returns a virtual kernel memory mapping for this object.
+    #[inline]
+    pub fn vmap<const SIZE: usize>(&self) -> Result<VMapRef<'_, T, C, SIZE>> {
+        self.make_vmap()
+    }
+
+    /// Creates and returns an owned reference to a virtual kernel memory mapping for this object.
+    #[inline]
+    pub fn owned_vmap<const SIZE: usize>(&self) -> Result<VMapOwned<T, C, SIZE>> {
+        self.make_vmap()
+    }
 }
 
 impl<T: DriverObject, C: DeviceContext> Deref for Object<T, C> {
@@ -257,7 +339,6 @@ impl<T: DriverObject, C: DeviceContext> driver::AllocImpl for Object<T, C> {
 
 impl<'a, T: DriverObject, C: DeviceContext> DmaResvGuard<'a, T, C> {
     #[inline(always)]
-    #[expect(unused)]
     fn new(obj: &'a Object<T, C>) -> Self {
         // SAFETY: This lock is initialized throughout the lifetime of `object`.
         unsafe { bindings::dma_resv_lock(obj.raw_dma_resv(), ptr::null_mut()) };
@@ -273,3 +354,232 @@ fn drop(&mut self) {
         unsafe { bindings::dma_resv_unlock(self.0.raw_dma_resv()) };
     }
 }
+
+macro_rules! impl_vmap_io_capable {
+    ($impl:ident, $ty:ty) => {
+        impl<D, R, C, const SIZE: usize> IoCapable<$ty> for $impl<D, R, C, SIZE>
+        where
+            D: DriverObject,
+            C: DeviceContext,
+            R: Deref<Target = Object<D, C>>,
+        {
+            #[inline(always)]
+            unsafe fn io_read(&self, address: usize) -> $ty {
+                let ptr = address as *mut $ty;
+
+                // SAFETY: The safety contract of `io_read` guarantees that address is a valid
+                // address within the bounds of `Self` of at least the size of $ty, and is properly
+                // aligned.
+                unsafe { ptr::read(ptr) }
+            }
+
+            #[inline(always)]
+            unsafe fn io_write(&self, value: $ty, address: usize) {
+                let ptr = address as *mut $ty;
+
+                // SAFETY: The safety contract of `io_write` guarantees that address is a valid
+                // address within the bounds of `Self` of at least the size of $ty, and is properly
+                // aligned.
+                unsafe { ptr::write(ptr, value) }
+            }
+        }
+    };
+}
+
+/// A reference to a virtual mapping for an shmem-based GEM object in kernel address space.
+///
+/// # Invariants
+///
+/// - The size of `owner` is >= SIZE.
+/// - The memory pointed to by addr remains valid at least until this object is dropped.
+pub struct VMap<D, R, C = Registered, const SIZE: usize = 0>
+where
+    D: DriverObject,
+    C: DeviceContext,
+    R: Deref<Target = Object<D, C>>,
+{
+    addr: *mut c_void,
+    owner: R,
+}
+
+/// An alias type for a reference to a shmem-based GEM object's VMap.
+pub type VMapRef<'a, D, C, const SIZE: usize = 0> = VMap<D, &'a Object<D, C>, C, SIZE>;
+
+/// An alias type for an owned reference to a shmem-based GEM object's VMap.
+pub type VMapOwned<D, C, const SIZE: usize = 0> = VMap<D, ARef<Object<D, C>>, C, SIZE>;
+
+impl<D, R, C, const SIZE: usize> VMap<D, R, C, SIZE>
+where
+    D: DriverObject,
+    C: DeviceContext,
+    R: Deref<Target = Object<D, C>>,
+{
+    /// Borrows a reference to the object that owns this virtual mapping.
+    #[inline(always)]
+    pub fn owner(&self) -> &Object<D, C> {
+        &self.owner
+    }
+}
+
+impl<D, R, C, const SIZE: usize> Drop for VMap<D, R, C, SIZE>
+where
+    D: DriverObject,
+    C: DeviceContext,
+    R: Deref<Target = Object<D, C>>,
+{
+    #[inline(always)]
+    fn drop(&mut self) {
+        // SAFETY:
+        // - Our existence is proof that this map was previously created using self.owner.
+        // - Since we are in Drop, we are guaranteed that no one will access the memory
+        //   through this mapping after calling this.
+        unsafe {
+            self.owner.raw_vunmap(bindings::iosys_map {
+                is_iomem: false,
+                __bindgen_anon_1: bindings::iosys_map__bindgen_ty_1 { vaddr: self.addr },
+            })
+        };
+    }
+}
+
+impl<D, R, C, const SIZE: usize> Io for VMap<D, R, C, SIZE>
+where
+    D: DriverObject,
+    C: DeviceContext,
+    R: Deref<Target = Object<D, C>>,
+{
+    #[inline(always)]
+    fn addr(&self) -> usize {
+        self.addr as usize
+    }
+
+    #[inline(always)]
+    fn maxsize(&self) -> usize {
+        self.owner.size()
+    }
+}
+
+impl<D, R, C, const SIZE: usize> IoKnownSize for VMap<D, R, C, SIZE>
+where
+    D: DriverObject,
+    C: DeviceContext,
+    R: Deref<Target = Object<D, C>>,
+{
+    const MIN_SIZE: usize = SIZE;
+}
+
+impl_vmap_io_capable!(VMap, u8);
+impl_vmap_io_capable!(VMap, u16);
+impl_vmap_io_capable!(VMap, u32);
+#[cfg(CONFIG_64BIT)]
+impl_vmap_io_capable!(VMap, u64);
+
+#[kunit_tests(rust_drm_gem_shmem)]
+mod tests {
+    use super::*;
+    use crate::{
+        drm::{
+            self,
+            UnregisteredDevice, //
+        },
+        faux,
+        page::PAGE_SIZE, //
+    };
+
+    // The bare minimum needed to create a fake drm driver for kunit
+
+    #[pin_data]
+    struct KunitData {}
+    struct KunitDriver;
+    struct KunitFile;
+    #[pin_data]
+    struct KunitObject {}
+
+    const INFO: drm::DriverInfo = drm::DriverInfo {
+        major: 0,
+        minor: 0,
+        patchlevel: 0,
+        name: c"kunit",
+        desc: c"Kunit",
+    };
+
+    impl drm::file::DriverFile for KunitFile {
+        type Driver = KunitDriver;
+
+        fn open(_dev: &drm::Device<KunitDriver>) -> Result<Pin<KBox<Self>>> {
+            Ok(KBox::new(Self, GFP_KERNEL)?.into())
+        }
+    }
+
+    impl gem::DriverObject for KunitObject {
+        type Driver = KunitDriver;
+        type Args = ();
+
+        fn new<C: DeviceContext>(
+            _dev: &drm::Device<KunitDriver, C>,
+            _size: usize,
+            _args: Self::Args,
+        ) -> impl PinInit<Self, Error> {
+            try_pin_init!(KunitObject {})
+        }
+    }
+
+    #[vtable]
+    impl drm::Driver for KunitDriver {
+        type Data = KunitData;
+        type File = KunitFile;
+        type Object<Ctx: DeviceContext> = Object<KunitObject, Ctx>;
+
+        const INFO: drm::DriverInfo = INFO;
+        const IOCTLS: &'static [drm::ioctl::DrmIoctlDescriptor] = &[];
+    }
+
+    fn create_drm_dev() -> Result<(faux::Registration, UnregisteredDevice<KunitDriver>)> {
+        // Create a faux DRM device so we can test gem object creation.
+        let data = try_pin_init!(KunitData {});
+        let dev = faux::Registration::new(c"Kunit", None)?;
+        let drm = UnregisteredDevice::new(dev.as_ref(), data)?;
+
+        Ok((dev, drm))
+    }
+
+    #[test]
+    fn compile_time_vmap_sizes() -> Result {
+        let (_dev, drm) = create_drm_dev()?;
+
+        let obj = Object::<KunitObject, _>::new(&drm, PAGE_SIZE, ObjectConfig::default(), ())?;
+
+        // Try creating a normal vmap
+        obj.vmap::<PAGE_SIZE>()?;
+
+        // Try creating a vmap that's smaller then the size we specified
+        obj.vmap::<{ PAGE_SIZE - 100 }>()?;
+
+        // Make sure creating a vmap that's too large fails
+        assert!(obj.vmap::<{ PAGE_SIZE + 200 }>().is_err());
+
+        Ok(())
+    }
+
+    #[test]
+    fn vmap_io() -> Result {
+        let (_dev, drm) = create_drm_dev()?;
+
+        let obj = Object::<KunitObject, _>::new(&drm, PAGE_SIZE, ObjectConfig::default(), ())?;
+
+        let vmap = obj.vmap::<PAGE_SIZE>()?;
+
+        vmap.write8(0xDE, 0x0);
+        assert_eq!(vmap.read8(0x0), 0xDE);
+        vmap.write32(0xFFFFFFFF, 0x20);
+
+        assert_eq!(vmap.read32(0x20), 0xFFFFFFFF);
+
+        assert_eq!(vmap.read8(0x20), 0xFF);
+        assert_eq!(vmap.read8(0x21), 0xFF);
+        assert_eq!(vmap.read8(0x22), 0xFF);
+        assert_eq!(vmap.read8(0x23), 0xFF);
+
+        Ok(())
+    }
+}
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device
  2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
  2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
  2026-06-04 19:24 ` [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions Lyude Paul
@ 2026-06-04 19:24 ` Lyude Paul
  2026-06-04 19:39   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  2026-06-04 19:24 ` [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table() Lyude Paul
  2026-06-04 20:03 ` Claude review: Rust bindings for gem shmem Claude Code Review Bot
  4 siblings, 2 replies; 14+ messages in thread
From: Lyude Paul @ 2026-06-04 19:24 UTC (permalink / raw)
  To: dri-devel, rust-for-linux, nouveau
  Cc: Alexandre Courbot, Gary Guo, Christian König, driver-core,
	Miguel Ojeda, Maarten Lankhorst, Alice Ryhl, Simona Vetter,
	linux-kernel, Sumit Semwal, linux-media, Rafael J . Wysocki,
	Thomas Zimmermann, Maxime Ripard, David Airlie, Benno Lossin,
	linaro-mm-sig, Danilo Krummrich, Mukesh Kumar Chaurasiya,
	Asahi Lina, Daniel Almeida, Lyude Paul, Greg Kroah-Hartman

When writing up some rust code that used faux devices for unit testing, I
noticed that we never actually added the Bound device context to
faux::Registration's AsRef<device::Device> implementation. This being said:
the Registration object itself is proof that a driver is bound to the
device - so this should be safe.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---
V18:
- Add notes from Danilo to safety comment.

 rust/kernel/faux.rs | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/rust/kernel/faux.rs b/rust/kernel/faux.rs
index 43b4974f48cd2..20ab638885354 100644
--- a/rust/kernel/faux.rs
+++ b/rust/kernel/faux.rs
@@ -25,7 +25,8 @@
 ///
 /// # Invariants
 ///
-/// `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
+/// - `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
+/// - This object is proof that the object described by this `Registration` is bound to a device.
 ///
 /// [`struct faux_device`]: srctree/include/linux/device/faux.h
 pub struct Registration(NonNull<bindings::faux_device>);
@@ -59,10 +60,15 @@ fn as_raw(&self) -> *mut bindings::faux_device {
     }
 }
 
-impl AsRef<device::Device> for Registration {
-    fn as_ref(&self) -> &device::Device {
-        // SAFETY: The underlying `device` in `faux_device` is guaranteed by the C API to be
-        // a valid initialized `device`.
+impl AsRef<device::Device<device::Bound>> for Registration {
+    fn as_ref(&self) -> &device::Device<device::Bound> {
+        // SAFETY:
+        // - The underlying `device` in `faux_device` is guaranteed by the C API to be a valid
+        //   initialized `device`.
+        // - faux_match() always returns 1, and probe runs synchronously (PROBE_FORCE_SYNCHRONOUS).
+        // - suppress_bind_attrs = true on faux_driver prevents userspace-triggered unbind via sysfs
+        // - mem::forget(Registration) is not a problem; if the Registration is leaked, the faux
+        //   device stays bound forever.
         unsafe { device::Device::from_raw(addr_of_mut!((*self.as_raw()).dev)) }
     }
 }
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table()
  2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
                   ` (2 preceding siblings ...)
  2026-06-04 19:24 ` [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device Lyude Paul
@ 2026-06-04 19:24 ` Lyude Paul
  2026-06-04 19:54   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  2026-06-04 20:03 ` Claude review: Rust bindings for gem shmem Claude Code Review Bot
  4 siblings, 2 replies; 14+ messages in thread
From: Lyude Paul @ 2026-06-04 19:24 UTC (permalink / raw)
  To: dri-devel, rust-for-linux, nouveau
  Cc: Alexandre Courbot, Gary Guo, Christian König, driver-core,
	Miguel Ojeda, Maarten Lankhorst, Alice Ryhl, Simona Vetter,
	linux-kernel, Sumit Semwal, linux-media, Rafael J . Wysocki,
	Thomas Zimmermann, Maxime Ripard, David Airlie, Benno Lossin,
	linaro-mm-sig, Danilo Krummrich, Mukesh Kumar Chaurasiya,
	Asahi Lina, Daniel Almeida, Lyude Paul, Greg Kroah-Hartman

In order to do this, we need to be careful to ensure that any interface we
expose for scatterlists ensures that any mappings created from one are
destroyed on driver-unbind. To do this, we introduce a Devres resource into
shmem::Object that we use in order to ensure that we release any SGTable
mappings on driver-unbind.

There's some other slightly unfortunate caveats of this:

* Drivers don't have explicit control at the moment over when unmapping
  happens (which is exactly the same as the C side atm, so it might not be
  a problem).
* We can't just return `SGTableMap` to the user through an Arc to attempt
  to fix the last caveat - because that implies the gem object would need
  to hold a reference count to the scatterlist mapping, which just leaves
  us with the same problem.

Signed-off-by: Lyude Paul <lyude@redhat.com>

---
V3:
* Rename OwnedSGTable to shmem::SGTable. Since the current version of the
  SGTable abstractions now has a `Owned` and `Borrowed` variant, I think
  renaming this to shmem::SGTable makes things less confusing.
  We do however, keep the name of owned_sg_table() as-is.
V4:
* Clarify safety comments for SGTable to explain why the object is
  thread-safe.
* Rename from SGTableRef to SGTable
V10:
* Use Devres in order to ensure that SGTables are revocable, and are
  unmapped on driver-unbind.
V11:
* s/create_sg_table()/get_sg_table()
* Get rid of extraneous `ret = ` in shmem::Object::get_sg_table()
V12:
* Actually move sgt_res in this patch and not the next one
V13:
* Use DmaResvGuard suggestion from Alexander
* Use Alexander's (much better) solution for get_sg_table()
* Use SetOnce instead of UnsafeCell
* s/SGTableRef/SGTableMap
* Fix typo in SGTableMap documentation
* Create fallible constructor for SGTableMap
* Don't reuse dma_resv lock for protecting Object contents, just use Mutex
  + SetOnce
* Drop use of drm_gem_shmem_get_pages_sgt_locked(), since we don't need to
  hold the dma_resv lock ourselves for anything but this function.
* Check that the device we receive in the bounds for sg_table() and
  owned_sg_table() that said Device is in fact, the correct device.
* Remove redundant docs in owned_sg_table(), just point it back to
  sg_table().
* Implement Deborah's suggestion to fix double-free in
  free_callback()
* Restore original order of Object<T>
* Fix doc typo for SGTableMap
V14:
* Use new InitOnce container over the Mutex/SetOnce horror show we had
  before.
* Start using LazyInit container for storing Devres for sgt unmap
* Add some kunit tests for sg_table (not sure why I didn't do this before)
  using some of the boilerplate code leftover from the vmap bindings
* Get rid of the owned SGTable variant for now, we'll add it back in a
  future patch if people actually need it.
* Use new LazyInit container from me to get rid of the horrid
  Mutex<SetOnce<>> mess.
* Add the best we can do for unit tests w/r/t SGTable at the moment
V16:
* Get rid of LazyInit, go back to SetOnce, use trick that Alice recommended
  that is a lot cleaner.
* Fix horrid rebasing mistake
V17:
* Rebase
* Fix missing safety comment in free_callback() (we forgot to justify why
  &mut is safe in `unsafe { &mut (*this).sgt_res }.reset()`)
V18:
* Use ManuallyDrop instead of SetOnce::reset()

 rust/kernel/drm/gem/shmem.rs | 172 +++++++++++++++++++++++++++++++++--
 1 file changed, 162 insertions(+), 10 deletions(-)

diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
index 1f05a5bc5fe66..a9970fca1d298 100644
--- a/rust/kernel/drm/gem/shmem.rs
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -11,6 +11,11 @@
 
 use crate::{
     container_of,
+    device::{
+        self,
+        Bound, //
+    },
+    devres::*,
     drm::{
         driver,
         gem,
@@ -19,20 +24,32 @@
         DeviceContext,
         Registered, //
     },
-    error::to_result,
+    error::{
+        from_err_ptr,
+        to_result, //
+    },
     io::{
         Io,
         IoCapable,
         IoKnownSize, //
     },
     prelude::*,
-    sync::aref::ARef,
+    scatterlist,
+    sync::{
+        aref::ARef,
+        new_mutex,
+        Mutex,
+        SetOnce, //
+    },
     types::Opaque, //
 };
 use core::{
     ffi::c_void,
     marker::PhantomData,
-    mem::MaybeUninit, //
+    mem::{
+        ManuallyDrop,
+        MaybeUninit, //
+    },
     ops::{
         Deref,
         DerefMut, //
@@ -87,6 +104,11 @@ pub struct Object<T: DriverObject, C: DeviceContext = Registered> {
     obj: Opaque<bindings::drm_gem_shmem_object>,
     /// Parent object that owns this object's DMA reservation object.
     parent_resv_obj: Option<ARef<Object<T, C>>>,
+    /// Devres object for unmapping any SGTable on driver-unbind.
+    sgt_res: ManuallyDrop<SetOnce<Devres<SGTableMap<T, C>>>>,
+    #[pin]
+    /// Lock for protecting initialization of `sgt_res`.
+    sgt_lock: Mutex<()>,
     #[pin]
     inner: T,
     _ctx: PhantomData<C>,
@@ -145,6 +167,8 @@ pub fn new(
             try_pin_init!(Self {
                 obj <- Opaque::init_zeroed(),
                 parent_resv_obj: config.parent_resv_obj.map(|p| p.into()),
+                sgt_res: ManuallyDrop::new(SetOnce::new()),
+                sgt_lock <- new_mutex!(()),
                 inner <- T::new(dev, size, args),
                 _ctx: PhantomData::<C>,
             }),
@@ -189,18 +213,26 @@ extern "C" fn free_callback(obj: *mut bindings::drm_gem_object) {
         // - DRM always passes a valid gem object here
         // - We used drm_gem_shmem_create() in our create_gem_object callback, so we know that
         //   `obj` is contained within a drm_gem_shmem_object
-        let this = unsafe { container_of!(obj, bindings::drm_gem_shmem_object, base) };
-
-        // SAFETY:
-        // - We're in free_callback - so this function is safe to call.
-        // - We won't be using the gem resources on `this` after this call.
-        unsafe { bindings::drm_gem_shmem_release(this) };
+        let base = unsafe { container_of!(obj, bindings::drm_gem_shmem_object, base) };
 
         // SAFETY:
         // - We verified above that `obj` is valid, which makes `this` valid
         // - This function is set in AllocOps, so we know that `this` is contained within a
         //   `Object<T, C>`
-        let this = unsafe { container_of!(Opaque::cast_from(this), Self, obj) }.cast_mut();
+        let this = unsafe { container_of!(Opaque::cast_from(base), Self, obj) }.cast_mut();
+
+        // We need to drop `sgt_res` first, since doing so requires that the GEM object is still
+        // alive.
+        // SAFETY:
+        // - We verified above that `this` is valid.
+        // - We are in free_callback, guaranteeing we have exclusive access to `this` and that
+        //   `sgt_res` will not be used after dropping it here.
+        unsafe { ManuallyDrop::drop(&mut (*this).sgt_res) };
+
+        // SAFETY:
+        // - We're in free_callback - so this function is safe to call.
+        // - We won't be using the gem resources on `this` after this call.
+        unsafe { bindings::drm_gem_shmem_release(base) };
 
         // SAFETY: We're recovering the Kbox<> we created in gem_create_object()
         let _ = unsafe { KBox::from_raw(this) };
@@ -279,6 +311,45 @@ pub fn vmap<const SIZE: usize>(&self) -> Result<VMapRef<'_, T, C, SIZE>> {
     pub fn owned_vmap<const SIZE: usize>(&self) -> Result<VMapOwned<T, C, SIZE>> {
         self.make_vmap()
     }
+
+    /// Creates (if necessary) and returns an immutable reference to a scatter-gather table of DMA
+    /// pages for this object.
+    ///
+    /// This will pin the object in memory. It is expected that `dev` should be a pointer to the
+    /// same [`device::Device`] which `self` belongs to, otherwise this function will return
+    /// `Err(EINVAL)`.
+    pub fn sg_table<'a>(
+        &'a self,
+        dev: &'a device::Device<Bound>,
+    ) -> Result<&'a scatterlist::SGTable> {
+        if dev.as_raw() != self.dev().as_ref().as_raw() {
+            return Err(EINVAL);
+        }
+
+        let sgt_res = 'out: {
+            // Fast path: sgt_res is already initialized
+            if let Some(sgt_res) = self.sgt_res.as_ref() {
+                break 'out sgt_res;
+            }
+
+            // Slow path: Grab the lock and see if we need to initialize sgt_res.
+            let _guard = self.sgt_lock.lock();
+
+            // If someone initialized it while we were waiting, we can exit early.
+            if let Some(sgt_res) = self.sgt_res.as_ref() {
+                break 'out sgt_res;
+            }
+
+            // If not, finish initializing and return.
+            self.sgt_res
+                .populate(Devres::new(dev, SGTableMap::new(self))?);
+
+            // SAFETY: We just populated sgt_res above.
+            unsafe { self.sgt_res.as_ref().unwrap_unchecked() }
+        };
+
+        Ok(sgt_res.access(dev)?)
+    }
 }
 
 impl<T: DriverObject, C: DeviceContext> Deref for Object<T, C> {
@@ -474,6 +545,63 @@ impl<D, R, C, const SIZE: usize> IoKnownSize for VMap<D, R, C, SIZE>
 #[cfg(CONFIG_64BIT)]
 impl_vmap_io_capable!(VMap, u64);
 
+/// A reference to a GEM object that is known to have a mapped [`SGTable`].
+///
+/// This is used by the Rust bindings with [`Devres`] in order to ensure that mappings for SGTables
+/// on GEM shmem objects are revoked on driver-unbind.
+///
+/// # Invariants
+///
+/// - `self.obj` always points to a valid GEM object.
+/// - This object is proof that `self.obj.owner.sgt` has an initialized and valid
+///   [`scatterlist::SGTable`].
+pub struct SGTableMap<T: DriverObject, C: DeviceContext> {
+    obj: NonNull<Object<T, C>>,
+}
+
+impl<T: DriverObject, C: DeviceContext> Deref for SGTableMap<T, C> {
+    type Target = scatterlist::SGTable;
+
+    fn deref(&self) -> &Self::Target {
+        // SAFETY:
+        // - The NonNull is guaranteed to be valid via our type invariants.
+        // - The sgt field is guaranteed to be initialized and valid via our type invariants.
+        unsafe { scatterlist::SGTable::from_raw((*self.obj.as_ref().as_raw_shmem()).sgt) }
+    }
+}
+
+impl<T: DriverObject, C: DeviceContext> Drop for SGTableMap<T, C> {
+    fn drop(&mut self) {
+        // SAFETY: `obj` is always valid via our type invariants
+        let obj = unsafe { self.obj.as_ref() };
+        let _lock = DmaResvGuard::new(obj);
+
+        // SAFETY: We acquired the lock needed for calling this function above
+        unsafe { bindings::__drm_gem_shmem_free_sgt_locked(obj.as_raw_shmem()) };
+    }
+}
+
+impl<T: DriverObject, C: DeviceContext> SGTableMap<T, C> {
+    fn new(obj: &Object<T, C>) -> impl Init<Self, Error> {
+        // INVARIANT:
+        // - We call drm_gem_shmem_get_pages_sgt_locked below and check whether or not it
+        //   succeeds, fulfilling the invariant of SGTableMap that the object's `sgt` field is
+        //   initialized.
+        // SAFETY:
+        // - `obj` is fully initialized, making this function safe to call.
+        from_err_ptr(unsafe { bindings::drm_gem_shmem_get_pages_sgt(obj.as_raw_shmem()) })?;
+
+        Ok(Self { obj: obj.into() })
+    }
+}
+
+// SAFETY: The NonNull in SGTableMap is guaranteed valid by our type invariants, and the GEM object
+// it points to is guaranteed to be thread-safe.
+unsafe impl<T: DriverObject, C: DeviceContext> Send for SGTableMap<T, C> {}
+// SAFETY: The NonNull in SGTableMap is guaranteed valid by our type invariants, and the GEM object
+// it points to is guaranteed to be thread-safe.
+unsafe impl<T: DriverObject, C: DeviceContext> Sync for SGTableMap<T, C> {}
+
 #[kunit_tests(rust_drm_gem_shmem)]
 mod tests {
     use super::*;
@@ -582,4 +710,28 @@ fn vmap_io() -> Result {
 
         Ok(())
     }
+
+    // TODO: I would love to actually test the success paths of sg_table(), but that would require
+    // also implementing dummy dma_ops so that trying to create a mapping doesn't explode. So, leave
+    // that for someone else.
+
+    // Ensures that passing the wrong device to sg_table() fails as we expect, and also ensure it
+    // skips initializing `sgt_res` since we could otherwise create `sgt_res` with the wrong device
+    // bound to it.
+    #[test]
+    fn fail_sg_table_on_wrong_dev() -> Result {
+        let (_dev, drm) = create_drm_dev()?;
+        let wrong_dev = faux::Registration::new(c"EvilKunit", None)?;
+
+        let obj = Object::<KunitObject, _>::new(&drm, PAGE_SIZE, ObjectConfig::default(), ())?;
+
+        assert_eq!(obj.sg_table(wrong_dev.as_ref()).err().unwrap(), EINVAL);
+
+        // If sgt_res was not initialized mistakenly with the wrong device, this should still fail.
+        assert_eq!(obj.sg_table(wrong_dev.as_ref()).err().unwrap(), EINVAL);
+
+        // TODO: Someday, we should test that creating an sg_table here still succeeds.
+
+        Ok(())
+    }
 }
-- 
2.54.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device
  2026-06-04 19:24 ` [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device Lyude Paul
@ 2026-06-04 19:39   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: sashiko-bot @ 2026-06-04 19:39 UTC (permalink / raw)
  To: Lyude Paul; +Cc: linux-media, ojeda, dri-devel

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The `Registration` struct's `# Invariants` documentation was updated with a new invariant, but the `// INVARIANT:` comment in the `Registration::new` constructor was not updated to explain why this new invariant is satisfied.
- [Low] Typo in the new type invariant comment: it incorrectly states the object is 'bound to a device' instead of 'bound to a driver'.
--

commit d541fc9c1199eb4e3a390c6348b6b03f9492aacc
Author: Lyude Paul <lyude@redhat.com>

rust: faux: Allow retrieving a bound Device

This commit updates faux::Registration to implement AsRef for a bound
device instead of a generic device. It also adds a new invariant to the
Registration struct to document that the object is proof of a driver being
bound to the device.

> diff --git a/rust/kernel/faux.rs b/rust/kernel/faux.rs
> index 43b4974f48cd2..20ab638885354 100644
> --- a/rust/kernel/faux.rs
> +++ b/rust/kernel/faux.rs
> @@ -25,7 +25,8 @@
>  ///
>  /// # Invariants
>  ///
> -/// `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
> +/// - `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
> +/// - This object is proof that the object described by this `Registration` is bound to a device.

[Severity: Low]
This isn't a bug, but there appears to be a typo here. The commit message
states that the Registration object is proof that "a driver is bound to the
device". Should this invariant say it is bound to a "driver" instead of
a "device"?

[Severity: Low]
Since a new invariant was added to the documentation here, does the
// INVARIANT: comment in Registration::new() also need to be updated to
explain why this new invariant is satisfied?

Currently, the comment in Registration::new() only explains the first
invariant:

    // INVARIANT: The device will remain registered until faux_device_destroy()
    // is called, which happens in our Drop implementation.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604192740.659240-1-lyude@redhat.com?part=3

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper
  2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
@ 2026-06-04 19:39   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: sashiko-bot @ 2026-06-04 19:39 UTC (permalink / raw)
  To: Lyude Paul; +Cc: ojeda, linux-media, dri-devel

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] `DmaResvGuard` implicitly implements `Send`, allowing the `ww_mutex` to be unlocked on a different thread than the one that acquired it, violating strict kernel mutex semantics.
- [Medium] Missing `#[must_use]` attribute on the `DmaResvGuard` lock guard.
- [Low] Incorrect use of `#[inline(always)]` for small abstraction functions that do not use `build_assert!()`.
--

commit 83465c025b759f686444735d2b770912987eb833
Author: Lyude Paul <lyude@redhat.com>

rust: drm: gem: shmem: Add DmaResvGuard helper

Just a temporary holdover to make locking/unlocking the dma_resv lock much
easier.

> diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
> index 34af402899a0e..4cf038f7afb71 100644
> --- a/rust/kernel/drm/gem/shmem.rs
> +++ b/rust/kernel/drm/gem/shmem.rs
[ ... ]
> @@ -235,3 +238,29 @@ impl<T: DriverObject, C: DeviceContext> driver::AllocImpl for Object<T, C> {
>          dumb_map_offset: None,
>      };
>  }
> +
> +/// Private helper-type for holding the `dma_resv` object for a GEM shmem object.
> +///
> +/// When this is dropped, the `dma_resv` lock is dropped as well.
> +///
> +// TODO: This should be replace with a WwMutex equivalent once we have such bindings in the kernel.
> +struct DmaResvGuard<'a, T: DriverObject, C: DeviceContext = Registered>(&'a Object<T, C>);

[Severity: High]
Does this struct implicitly implement Send?

Since the wrapped type Object<T, C> is Sync, a shared reference 
&'a Object<T, C> is both Send and Sync. This makes DmaResvGuard implicitly 
Send. However, bindings::dma_resv_lock acquires a ww_mutex, and its Drop 
implementation releases it. Linux kernel mutexes are strictly bound to the 
task (current) that acquired them.

If safe Rust code sends the DmaResvGuard to another thread and drops it 
there, mutex_unlock will be called by a non-owner thread. Could this cause 
kernel panics or break mutual exclusion, and should DmaResvGuard be 
explicitly marked as !Send?

[Severity: Medium]
Should this struct be marked with #[must_use]?

Without #[must_use], users might inadvertently call DmaResvGuard::new(obj) 
as a standalone statement without binding it to a variable, causing the guard 
to drop immediately. This would leave the subsequent critical section 
unprotected.

> +
> +impl<'a, T: DriverObject, C: DeviceContext> DmaResvGuard<'a, T, C> {
> +    #[inline(always)]

[Severity: Low]
This isn't a bug, but does this violate the Rust subsystem coding guidelines?

According to Documentation/rust/coding-guidelines.rst, for abstractions 
only: functions that are small or forwarding to a binding call should be 
annotated with #[inline]. The #[inline(always)] annotation is strictly 
reserved for functions using build_assert!() that depend on function 
parameters.

> +    #[expect(unused)]
> +    fn new(obj: &'a Object<T, C>) -> Self {
> +        // SAFETY: This lock is initialized throughout the lifetime of `object`.
> +        unsafe { bindings::dma_resv_lock(obj.raw_dma_resv(), ptr::null_mut()) };
> +
> +        Self(obj)
> +    }
> +}
> +
> +impl<'a, T: DriverObject, C: DeviceContext> Drop for DmaResvGuard<'a, T, C> {
> +    #[inline(always)]

[Severity: Low]
This isn't a bug, but should this be #[inline] instead of #[inline(always)]?

As mentioned above, the guidelines reserve #[inline(always)] for functions 
using build_assert!() that depend on function parameters.

> +    fn drop(&mut self) {
> +        // SAFETY: We are releasing the lock grabbed during the creation of this object.
> +        unsafe { bindings::dma_resv_unlock(self.0.raw_dma_resv()) };
> +    }
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604192740.659240-1-lyude@redhat.com?part=1

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions
  2026-06-04 19:24 ` [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions Lyude Paul
@ 2026-06-04 19:41   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: sashiko-bot @ 2026-06-04 19:41 UTC (permalink / raw)
  To: Lyude Paul; +Cc: dri-devel, linux-media, ojeda

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `IoCapable` implementation for `VMap` uses non-volatile `ptr::read` and `ptr::write`, allowing the compiler to optimize away or reorder memory accesses to shared device memory.
- [Medium] `VMap` and `VMapOwned` are implicitly `!Send` and `!Sync` due to the `*mut c_void` field, artificially restricting the mapping to the thread that created it.
- [Low] Missing `// INVARIANT:` comment explaining `VMap` memory validity at its construction site, violating subsystem guidelines.
--

commit b418d73acbe560c4eda85331900333d19c6ae108
Author: Lyude Paul <lyude@redhat.com>

rust: drm: gem: shmem: Add vmap functions

One of the more obvious use cases for gem shmem objects is the ability to
create mappings into their contents. So, let's hook this up in our rust
bindings.

> diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
> index 4cf038f7afb71..a20b0c0dac6bd 100644
> --- a/rust/kernel/drm/gem/shmem.rs
> +++ b/rust/kernel/drm/gem/shmem.rs

[ ... ]

> @@ -188,6 +196,80 @@ extern "C" fn free_callback(obj: *mut bindings::drm_gem_object) {
>          // SAFETY: We're recovering the Kbox<> we created in gem_create_object()
>          let _ = unsafe { KBox::from_raw(this) };
>      }
> +
> +    /// Attempt to create a vmap from the gem object, and confirm the size of said vmap.
> +    fn make_vmap<'a, R, const SIZE: usize>(&'a self) -> Result<VMap<T, R, C, SIZE>>
> +    where
> +        R: Deref<Target = Self> + From<&'a Self>,
> +    {

[ ... ]

> +        // XXX: We don't currently support iomem allocations
> +        if map.is_iomem {
> +            // SAFETY:
> +            // - The vmap operation above succeeded, guaranteeing that `map` points to a valid
> +            //   memory mapping.
> +            // - We checked that this is an iomem allocation, making it safe to read vaddr_iomem
> +            unsafe { self.raw_vunmap(map) };
> +
> +            Err(ENOTSUPP)
> +        } else {
> +            Ok(VMap {
> +                // SAFETY: We checked that this is not an iomem allocation, making it safe to read
> +                // vaddr
> +                addr: unsafe { map.__bindgen_anon_1.vaddr },
> +                owner: self.into(),
> +            })

[Severity: Low]
This isn't a bug, but there's a missing invariant comment here.

The Rust subsystem guidelines mention that when a struct with an
# Invariants documentation section is constructed, the code should have an
// INVARIANT: comment explaining why the invariants are satisfied.

Would it make sense to add a comment here explaining why the memory remains
valid until dropped?

> +        }
> +    }

[ ... ]

> @@ -264,3 +345,232 @@ fn drop(&mut self) {
>          unsafe { bindings::dma_resv_unlock(self.0.raw_dma_resv()) };
>      }
>  }
> +
> +macro_rules! impl_vmap_io_capable {
> +    ($impl:ident, $ty:ty) => {
> +        impl<D, R, C, const SIZE: usize> IoCapable<$ty> for $impl<D, R, C, SIZE>
> +        where
> +            D: DriverObject,
> +            C: DeviceContext,
> +            R: Deref<Target = Object<D, C>>,
> +        {
> +            #[inline(always)]
> +            unsafe fn io_read(&self, address: usize) -> $ty {
> +                let ptr = address as *mut $ty;
> +
> +                // SAFETY: The safety contract of `io_read` guarantees that address is a valid
> +                // address within the bounds of `Self` of at least the size of $ty, and is properly
> +                // aligned.
> +                unsafe { ptr::read(ptr) }
> +            }

[Severity: High]
Can this allow the compiler to improperly optimize these memory accesses?

Since VMap represents GEM shmem objects mapped into the kernel virtual
address space, this memory might be concurrently accessed by hardware or
userspace.

Using standard non-volatile ptr::read and ptr::write allows the compiler
to cache values in registers, coalesce writes, or elide them entirely. The C
equivalent (iosys_map_rd and iosys_map_wr) uses READ_ONCE() and
WRITE_ONCE() for this reason.

Should this use ptr::read_volatile() to safely access the shared memory?

> +
> +            #[inline(always)]
> +            unsafe fn io_write(&self, value: $ty, address: usize) {
> +                let ptr = address as *mut $ty;
> +
> +                // SAFETY: The safety contract of `io_write` guarantees that address is a valid
> +                // address within the bounds of `Self` of at least the size of $ty, and is properly
> +                // aligned.
> +                unsafe { ptr::write(ptr, value) }
> +            }

[Severity: High]
Similar to the io_read() implementation above, does this write need to use
ptr::write_volatile() to prevent the compiler from caching or coalescing
these shared memory writes?

> +        }
> +    };
> +}
> +
> +/// A reference to a virtual mapping for an shmem-based GEM object in kernel address space.
> +///
> +/// # Invariants
> +///
> +/// - The size of `owner` is >= SIZE.
> +/// - The memory pointed to by addr remains valid at least until this object is dropped.
> +pub struct VMap<D, R, C = Registered, const SIZE: usize = 0>
> +where
> +    D: DriverObject,
> +    C: DeviceContext,
> +    R: Deref<Target = Object<D, C>>,
> +{
> +    addr: *mut c_void,
> +    owner: R,
> +}

[Severity: Medium]
Does this unintentionally restrict the mapping to the thread that created it?

Because VMap stores its mapping address as a raw pointer
addr: *mut c_void, it implicitly lacks the Send and Sync traits in Rust.
This means VMap and VMapOwned cannot be safely transferred or shared
across concurrency boundaries.

Since the kernel's virtual mapping should be globally valid as long as the
underlying owner object provides safe concurrent access, should explicit
unsafe impl Send and unsafe impl Sync be provided for this struct?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604192740.659240-1-lyude@redhat.com?part=2

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table()
  2026-06-04 19:24 ` [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table() Lyude Paul
@ 2026-06-04 19:54   ` sashiko-bot
  2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: sashiko-bot @ 2026-06-04 19:54 UTC (permalink / raw)
  To: Lyude Paul; +Cc: linux-media, ojeda, dri-devel

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] SGTableMap::drop frees the scatter-gather table without decrementing the backing pages reference count, causing a permanent memory leak if Devres initialization fails.
--

commit 28826d4b9c036cf868c70bbd1c12d628314a0735
Author: Lyude Paul <lyude@redhat.com>

rust: drm: gem: Introduce shmem::Object::sg_table()

This commit introduces sg_table() to shmem::Object and utilizes a Devres
resource to ensure SGTable mappings are released on driver-unbind.

> diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
> index a20b0c0dac6bd..f3c893c7fbf4f 100644
> --- a/rust/kernel/drm/gem/shmem.rs
> +++ b/rust/kernel/drm/gem/shmem.rs

[ ... ]

> @@ -270,6 +302,45 @@ pub fn vmap<const SIZE: usize>(&self) -> Result<VMapRef<'_, T, C, SIZE>> {
>      pub fn owned_vmap<const SIZE: usize>(&self) -> Result<VMapOwned<T, C, SIZE>> {
>          self.make_vmap()
>      }
> +
> +    /// Creates (if necessary) and returns an immutable reference to a scatter-gather table of DMA
> +    /// pages for this object.
> +    ///
> +    /// This will pin the object in memory. It is expected that `dev` should be a pointer to the
> +    /// same [`device::Device`] which `self` belongs to, otherwise this function will return
> +    /// `Err(EINVAL)`.
> +    pub fn sg_table<'a>(
> +        &'a self,
> +        dev: &'a device::Device<Bound>,
> +    ) -> Result<&'a scatterlist::SGTable> {
> +        if dev.as_raw() != self.dev().as_ref().as_raw() {
> +            return Err(EINVAL);
> +        }
> +
> +        let sgt_res = 'out: {

[ ... ]

> +            // If not, finish initializing and return.
> +            self.sgt_res
> +                .populate(Devres::new(dev, SGTableMap::new(self))?);

[Severity: Medium]
If Devres::new() returns an error here, will the newly created SGTableMap
be immediately dropped?

When SGTableMap::new() calls drm_gem_shmem_get_pages_sgt(), it pins the
backing pages by incrementing pages_use_count and caches the new sgt. If the
SGTableMap is dropped during this error path, it frees the SGT without
decrementing pages_use_count, leading to a permanent memory leak of the
backing pages.

> +
> +            // SAFETY: We just populated sgt_res above.
> +            unsafe { self.sgt_res.as_ref().unwrap_unchecked() }
> +        };

[ ... ]

> +impl<T: DriverObject, C: DeviceContext> Drop for SGTableMap<T, C> {
> +    fn drop(&mut self) {
> +        // SAFETY: `obj` is always valid via our type invariants
> +        let obj = unsafe { self.obj.as_ref() };
> +        let _lock = DmaResvGuard::new(obj);
> +
> +        // SAFETY: We acquired the lock needed for calling this function above
> +        unsafe { bindings::__drm_gem_shmem_free_sgt_locked(obj.as_raw_shmem()) };

[Severity: Medium]
Does this code leak the backing pages?

This function frees the SGT and sets shmem->sgt = NULL, but it omits a paired
call to drm_gem_shmem_put_pages_locked(). If this drop is triggered early
(such as when Devres::new() fails in Object::sg_table()), pages_use_count is
permanently incremented.

If the caller retries sg_table() after the failure, it will see
shmem->sgt == NULL and increment pages_use_count a second time. When the GEM
object is eventually released, drm_gem_shmem_release() will only decrement it
once, failing to reach 0 and triggering a drm_WARN_ON.

> +    }
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604192740.659240-1-lyude@redhat.com?part=4

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Claude review: Rust bindings for gem shmem
  2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
                   ` (3 preceding siblings ...)
  2026-06-04 19:24 ` [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table() Lyude Paul
@ 2026-06-04 20:03 ` Claude Code Review Bot
  4 siblings, 0 replies; 14+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 20:03 UTC (permalink / raw)
  To: dri-devel-reviews

Overall Series Review

Subject: Rust bindings for gem shmem
Author: Lyude Paul <lyude@redhat.com>
Patches: 9
Reviewed: 2026-06-05T06:03:37.473116

---

This is v18 of the Rust GEM shmem bindings series by Lyude Paul, adding vmap, scatter-gather table, and DMA reservation guard support to the existing Rust DRM GEM shmem abstraction. The series is well-structured with proper incremental patches and good test coverage where feasible.

**Key concerns:**

1. **`dma_resv_lock` return value is silently ignored** (patches 1 & 2). `dma_resv_lock()` wraps `ww_mutex_lock()` which returns an `int` — it can fail with `-EALREADY` or deadlock-related errors. The `DmaResvGuard::new()` discards this, which means a lock failure would leave the guard in a state where `Drop` calls `dma_resv_unlock()` on a lock that was never acquired. This is a real correctness bug.

2. **`__drm_gem_shmem_free_sgt_locked`** (patch 4) does not exist in the current drm-next tree. This is presumably a function introduced in the drm-rust-next branch that this series targets. Since we can't verify the contract, this is noted but not a blocker if the function exists in the target tree.

3. **`SGTableMap` stores a raw `NonNull<Object<T,C>>`** without holding a reference count (patch 4). The safety argument relies on the fact that `SGTableMap` lives inside a `SetOnce` field of the `Object` itself, so the object outlives it. This is correct but fragile — any future refactoring that moves `SGTableMap` out of the object would create a use-after-free. The invariant documentation is adequate but worth highlighting.

4. The overall Rust safety story is reasonable — proper use of `ManuallyDrop` for controlling drop ordering in `free_callback`, and the double-checked locking pattern for `sgt_res` initialization is correctly synchronized.

---

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Claude review: rust: drm: gem: shmem: Add DmaResvGuard helper
  2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
  2026-06-04 19:39   ` sashiko-bot
@ 2026-06-04 20:03   ` Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 20:03 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Bug — return value of `dma_resv_lock` is ignored:**

```rust
fn new(obj: &'a Object<T, C>) -> Self {
    // SAFETY: This lock is initialized throughout the lifetime of `object`.
    unsafe { bindings::dma_resv_lock(obj.raw_dma_resv(), ptr::null_mut()) };
    Self(obj)
}
```

`dma_resv_lock()` returns `int`. With `ctx` as NULL, `ww_mutex_lock` should succeed (no deadlock detection context), but it can still return `-EALREADY` if the caller already holds the lock. Ignoring the return value means on failure, the `Drop` impl will call `dma_resv_unlock()` on a lock that was never acquired — undefined behavior. At minimum, `new()` should return `Result<Self>` and propagate the error.

**Minor — `#[expect(unused)]` on `new()`:** This attribute is removed in patch 2, which is fine, but the helper itself is dead code in this patch. Consider squashing patches 1 and 2 since the guard has no users until patch 2.

**Comment nit:** The TODO comment about WwMutex is good forward-looking documentation.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Claude review: rust: drm: gem: shmem: Add vmap functions
  2026-06-04 19:24 ` [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions Lyude Paul
  2026-06-04 19:41   ` sashiko-bot
@ 2026-06-04 20:03   ` Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 20:03 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Generally well-structured.** The `make_vmap` → `vmap`/`owned_vmap` pattern with the generic `R: Deref<Target = Self> + From<&'a Self>` is clean and avoids code duplication.

**Lock/unlock sequencing in `make_vmap` looks correct:**
```rust
let guard = DmaResvGuard::new(self);
to_result(unsafe {
    bindings::drm_gem_shmem_vmap_locked(self.as_raw_shmem(), map.as_mut_ptr())
})?;
drop(guard);
```
The explicit `drop(guard)` before the iomem check + potential `raw_vunmap` is necessary since `raw_vunmap` re-acquires the lock. Good.

**`ENOTSUPP` for iomem:** The XXX comment acknowledges this limitation. `ENOTSUPP` vs `EOPNOTSUPP` — kernel convention typically uses `EOPNOTSUPP` for userspace-facing errors and `ENOTSUPP` for internal use. Since this is an internal Rust API, `ENOTSUPP` is acceptable but worth confirming intent.

**`IoCapable` macro — raw pointer casts from `usize`:**
```rust
unsafe fn io_read(&self, address: usize) -> $ty {
    let ptr = address as *mut $ty;
    unsafe { ptr::read(ptr) }
}
```
The `address` is a raw kernel virtual address cast from the `Io` trait's `addr()`. The safety contract is documented via `Io` trait bounds. This follows the existing kernel `Io` pattern so it's fine.

**Test coverage is good.** The `compile_time_vmap_sizes` test validates the SIZE invariant, and `vmap_io` exercises read/write paths including cross-type verification (write u32 then read individual u8 bytes).

**Byte-order assumption in test:**
```rust
vmap.write32(0xFFFFFFFF, 0x20);
assert_eq!(vmap.read8(0x20), 0xFF);
```
This works for `0xFFFFFFFF` regardless of endianness, but the pattern would be fragile for other values. Since all bytes are `0xFF` here, it's fine.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Claude review: rust: faux: Allow retrieving a bound Device
  2026-06-04 19:24 ` [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device Lyude Paul
  2026-06-04 19:39   ` sashiko-bot
@ 2026-06-04 20:03   ` Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 20:03 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Correct and well-justified change.** The `AsRef<device::Device>` → `AsRef<device::Device<device::Bound>>` change strengthens the type-level guarantee.

**Safety comment is thorough:**
```rust
// - faux_match() always returns 1, and probe runs synchronously (PROBE_FORCE_SYNCHRONOUS).
// - suppress_bind_attrs = true on faux_driver prevents userspace-triggered unbind via sysfs
// - mem::forget(Registration) is not a problem; if the Registration is leaked, the faux
//   device stays bound forever.
```
This is exactly the level of reasoning needed. The three points cover the key attack vectors against the `Bound` invariant.

**Potential downstream breakage:** Any existing code using `faux::Registration::as_ref()` where a `&device::Device` (without the `Bound` parameter) was expected will break. Since this is on drm-rust-next and the faux bindings are relatively new, this should be fine, but the cover letter doesn't mention this API change explicitly.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Claude review: rust: drm: gem: Introduce shmem::Object::sg_table()
  2026-06-04 19:24 ` [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table() Lyude Paul
  2026-06-04 19:54   ` sashiko-bot
@ 2026-06-04 20:03   ` Claude Code Review Bot
  1 sibling, 0 replies; 14+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 20:03 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Most complex patch — warrants careful scrutiny.**

**Drop ordering in `free_callback` is correct:**
```rust
unsafe { ManuallyDrop::drop(&mut (*this).sgt_res) };
unsafe { bindings::drm_gem_shmem_release(base) };
let _ = unsafe { KBox::from_raw(this) };
```
`sgt_res` must drop first because its `Drop` calls `__drm_gem_shmem_free_sgt_locked` which needs the GEM object alive. Then `drm_gem_shmem_release` cleans up the C-side shmem state. Then `KBox::from_raw` drops the remaining Rust fields. The `ManuallyDrop` pattern is the right choice here since `SetOnce::reset()` was removed in v18.

**Double-checked locking in `sg_table()` is correct:**
```rust
if let Some(sgt_res) = self.sgt_res.as_ref() {
    break 'out sgt_res;
}
let _guard = self.sgt_lock.lock();
if let Some(sgt_res) = self.sgt_res.as_ref() {
    break 'out sgt_res;
}
self.sgt_res.populate(Devres::new(dev, SGTableMap::new(self))?);
```
This requires that `SetOnce::as_ref()` is safe to call without holding `sgt_lock` (i.e., it provides atomic-like visibility). If `SetOnce` is implemented with proper memory ordering (which kernel `SetOnce` should be), this is correct. If not, there's a data race on the fast path.

**`SGTableMap::new` uses `from_err_ptr` with a `?` inside an `Init` returning closure:**
```rust
fn new(obj: &Object<T, C>) -> impl Init<Self, Error> {
    from_err_ptr(unsafe { bindings::drm_gem_shmem_get_pages_sgt(obj.as_raw_shmem()) })?;
    Ok(Self { obj: obj.into() })
}
```
This calls `drm_gem_shmem_get_pages_sgt` which acquires/releases `dma_resv` internally (it uses `dma_resv_lock_interruptible`). The return value (an `sg_table*`) is checked for errors via `from_err_ptr` but the actual pointer is then discarded — the implementation relies on the fact that `shmem->sgt` is set as a side effect. This is correct per the C implementation, but the discarded return value deserves a comment explaining this pattern.

**Device identity check:**
```rust
if dev.as_raw() != self.dev().as_ref().as_raw() {
    return Err(EINVAL);
}
```
Good — prevents creating a `Devres` bound to the wrong device, which would cause the revocation to fire at the wrong time or not at all.

**`SGTableMap` raw pointer storage:**
```rust
pub struct SGTableMap<T: DriverObject, C: DeviceContext> {
    obj: NonNull<Object<T, C>>,
}
```
This stores a non-refcounted pointer to the owning `Object`. The invariant is that `SGTableMap` lives inside the `Object`'s `sgt_res` field, so the object outlives it. The `ManuallyDrop` ensures `sgt_res` is dropped before the object in `free_callback`. This is sound but not self-documenting — a `// INVARIANT:` comment on the `obj` field explaining the lifetime relationship would help future maintainers.

**Test only covers the failure path:**
```rust
fn fail_sg_table_on_wrong_dev() -> Result {
```
The TODO explains that testing the success path would require dummy DMA ops. The failure test is useful — it confirms the device check prevents `sgt_res` from being populated with a wrong device. Good defensive test.

**`Send`/`Sync` for `SGTableMap`:** The safety justification references GEM object thread-safety, which is established by the existing `Send`/`Sync` impls on `Object`. This is correct.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2026-06-04 20:03 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-04 19:24 [PATCH v18 0/4] Rust bindings for gem shmem Lyude Paul
2026-06-04 19:24 ` [PATCH v18 1/4] rust: drm: gem: shmem: Add DmaResvGuard helper Lyude Paul
2026-06-04 19:39   ` sashiko-bot
2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
2026-06-04 19:24 ` [PATCH v18 2/4] rust: drm: gem: shmem: Add vmap functions Lyude Paul
2026-06-04 19:41   ` sashiko-bot
2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
2026-06-04 19:24 ` [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device Lyude Paul
2026-06-04 19:39   ` sashiko-bot
2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
2026-06-04 19:24 ` [PATCH v18 4/4] rust: drm: gem: Introduce shmem::Object::sg_table() Lyude Paul
2026-06-04 19:54   ` sashiko-bot
2026-06-04 20:03   ` Claude review: " Claude Code Review Bot
2026-06-04 20:03 ` Claude review: Rust bindings for gem shmem Claude Code Review Bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox