Re: [PATCH v1 16/16] mm/memory: support VM_MIXEDMAP in zap_special_vma_range()

On Wed, Mar 11, 2026 at 09:04:18AM -0300, Jason Gunthorpe wrote:

On Wed, Mar 11, 2026 at 09:38:45AM +0000, Alice Ryhl wrote:

quoted

It doesn't really make sense to have multiple binder VMAs. What happens
with Rust Binder is that process A is receiving transactions and has the
VMA mapped once.

IIRC the problem is the kernel doesn't guarentee singleton VMAs,
userspace can always clone them with fork or something. Did binder
solve this somehow?

The Binder VMA is DONTCOPY, so it will not be present after fork.

Since you can't assume there is only one VMA the locking becomes a
mess to cover all the cases where userspace can trigger a VMA clone.

address space deals with this internally.

Thus, zap_special_vma_range() is extremely hard to use.

I mean, the hard part about the locking is keeping them in sync. Binder
just doesn't do that. Only the original VMA gets pages inserted or
zapped. If you create a second VMA, you just get a useless read-only VMA
that you can't do anything with.

Alice