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

On Mon, Aug 24, 2026 at 10:48:08PM +0300, Artem Lytkin wrote:
> 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/[email protected]/
>
> 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?

I'd say you should build around it to start, anything that you need to use
that uses the legacy interface can be converted :)

I (should) have more patches coming next cycle to keep the conversions
coming.

One thing that might be difficult if you in some way rely on a driver that
needs conversion is that I am building out the infra as I go -
i.e. implementing stuff like ioremap, mapping kernels pages, etc. as
mmap_prepare() does it in a different way.

But on general principle - mmap_prepare is the future and building
abstractions around it makes sense.

>
> Artem

--
Cheers, Lorenzo