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: > > 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
