linux-kernel - Re: [PATCH v3 5/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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXM99J8s5ltmZ1hE@google.com>
Date: Fri, 23 Jan 2026 09:23:00 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Danilo Krummrich <dakr@...nel.org>, 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 v3 5/6] rust: gpuvm: add GpuVmCore::sm_unmap()'

On Thu, Jan 22, 2026 at 07:43:11PM -0300, Daniel Almeida wrote:
> Hi Alice,
> 
> > On 21 Jan 2026, at 08:31, Alice Ryhl <aliceryhl@...gle.com> wrote:
> > +/// Represents an `sm_step_unmap` operation that has not yet been completed.
> > +pub struct OpUnmap<'op, T: DriverGpuVm> {
> > +    op: &'op bindings::drm_gpuva_op_unmap,
> > +    _invariant: PhantomData<*mut &'op mut T>,
> 
> Would have been cool to explain why we have a pointer in this PhantomData.
> 
> Same elsewhere, IMHO. Helps with maintainability in the future.
> 
> (To be honest, I’m not really sure what’s going on here..)

Normally, when you have an OpUnmap<'long, T> Rust will let you convert
that into an OpUnmap<'short, T>, but I don't want that in this case.
Making such coercions impossible means that callers of sm_step_unmap()
cannot return the "wrong" OpUnmapped from the closure because the only
way to get an OpUnmapped with the right lifetime is to call remove() on
the OpUnmap you received.

(Otherwise, it may be possible to return an OpUnmapped from one
sm_step_unmap() call in another sm_step_unmap() call.)

There are various different types one can place in PhantomData to have
this effect. A mutable pointer is one choice. I could also have used:

	PhantomData<fn(&'op mut T) -> &'op mut T>

or a few other options.

Alice