linux-kernel - Re: [PATCH v4 6/6] rust: gpuvm: add GpuVmCore::sm

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] [day] [month] [year] [list]

Message-ID: <aYZMXiv4GvyjPxoa@um790>
Date: Fri, 6 Feb 2026 12:17:34 -0800
From: Deborah Brouwer <deborah.brouwer@...labora.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Danilo Krummrich <dakr@...nel.org>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Boris Brezillon <boris.brezillon@...labora.com>,
	Janne Grunau <j@...nau.net>,
	Matthew Brost <matthew.brost@...el.com>,
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
	Lyude Paul <lyude@...hat.com>,
	Asahi Lina <lina+kernel@...hilina.net>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v4 6/6] rust: gpuvm: add GpuVmCore::sm_map()

Hi Alice, I got a build error testing gpuvm v4 with Tyr.

On Fri, Jan 30, 2026 at 02:24:15PM +0000, Alice Ryhl wrote:
> Finally also add the operation for creating new mappings. Mapping
> operations need extra data in the context since they involve a vm_bo
> coming from the outside.
> 
> Co-developed-by: Asahi Lina <lina+kernel@...hilina.net>
> Signed-off-by: Asahi Lina <lina+kernel@...hilina.net>
> Reviewed-by: Daniel Almeida <daniel.almeida@...labora.com>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> ---
> +}
> +
> +impl<'op, T: DriverGpuVm> OpMap<'op, T> {
> +    /// The base address of the new mapping.
> +    pub fn addr(&self) -> u64 {
> +        self.op.va.addr
> +    }
> +
> +    /// The length of the new mapping.
> +    pub fn length(&self) -> u64 {
> +        self.op.va.range
> +    }
> +
> +    /// The offset within the [`drm_gem_object`](crate::gem::Object).
> +    pub fn gem_offset(&self) -> u64 {
> +        self.op.gem.offset
> +    }
> +
> +    /// The [`drm_gem_object`](crate::gem::Object) to map.
> +    pub fn obj(&self) -> &T::Object {
> +        // SAFETY: The `obj` pointer is guaranteed to be valid.
> +        unsafe { <T::Object as IntoGEMObject>::from_raw(self.op.gem.obj) }
> +    }
> +
> +    /// The [`GpuVmBo`] that the new VA will be associated with.
> +    pub fn vm_bo(&self) -> &GpuVmBo<T> {
> +        self.vm_bo
> +    }
> +
> +    /// Use the pre-allocated VA to carry out this map operation.
> +    pub fn insert(self, va: GpuVaAlloc<T>, va_data: impl PinInit<T::VaData>) -> OpMapped<'op, T> {
> +        let va = va.prepare(va_data);
> +        // SAFETY: By the type invariants we may access the interval tree.
> +        unsafe { bindings::drm_gpuva_map(self.vm_bo.gpuvm().as_raw(), va, self.op) };
> +
> +        let _gpuva_guard = self.vm_bo().lock_gpuva();
> +        // SAFETY: The va is prepared for insertion, and we hold the GEM lock.
> +        unsafe { bindings::drm_gpuva_link(va, self.vm_bo.as_raw()) };
> +
> +        OpMapped {
> +            _invariant: self._invariant,
> +        }

error[E0308]: mismatched types
  --> rust/kernel/drm/gpuvm/sm_ops.rs:98:25
   |
98 |             _invariant: self._invariant,
   |                         ^^^^^^^^^^^^^^^ expected `PhantomData<*mut &mut T>`, found `PhantomData<fn(&mut T) -> fn(&mut T)>`
   |
   = note: expected struct `core::marker::PhantomData<*mut &mut T>`
              found struct `core::marker::PhantomData<fn(&'op mut T) -> fn(&'op mut T)>`

Updating the PhantomData type for OpMapped to match OpMap
seems to fix it.

Deborah