Re: [PATCH v2 1/2] rust_binder: check ownership before using vma

[Artem Lytkin <iprintercanon@gmail.com>]

On Wed, Feb 18, 2026, Alice Ryhl wrote:
> The plan is to introduce more vma
> abstractions to avoid this unsafe access to vm_ops and vm_private_data,
> but for now let's start with the simplest possible fix.
[...]
> (We probably still want to do both, but
> the vm_ops->close callback will be added later as part of the follow-up
> vma API changes.)

Alice, is that follow-up still on your list, or would you rather someone
else took it?

I'd like to add the missing pieces to kernel::mm::virt: a VmOperations
trait with open, close and fault, a typed way to install it together
with the private data on a VmaNew, a VmFault wrapper, and a PFN-map
typestate next to VmaMixedMap with vmf_insert_pfn_prot() on it. Binder
would then drop BINDER_VM_OPS and the raw vm_ops pointer compare and get
a close callback like the C driver has. Tyr needs the fault and PFN-map
half of that for its user MMIO mmap. The first two patches of
Collabora's Tyr series are the pgprot_noncached and pgoff helpers; they
have had no replies since 7 May, so I'd build on those rather than
duplicate them:

  https://lore.kernel.org/all/20260507-tyr-mmap-v1-0-eec048a23c25@collabora.com/

One design question first, for you and Lorenzo. f_op->mmap is
deprecated in favour of mmap_prepare, where a driver sets desc->vm_ops
instead of touching the vma, and the Rust side only has the old mmap
path today. Should the vm_ops abstraction be built around mmap_prepare
from the start, with a Rust mmap_prepare hook for miscdevice next to
it, or is landing it on the existing VmaNew an acceptable first step?

Artem