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

On 3/9/26 15:29, Jason Gunthorpe wrote:
> On Fri, Feb 27, 2026 at 09:08:47PM +0100, David Hildenbrand (Arm) wrote:
>> There is demand for also zapping page table entries by drivers in
>> VM_MIXEDMAP VMAs[1].
>>
>> Nothing really speaks against supporting VM_MIXEDMAP for driver use. We
>> just don't want arbitrary drivers to zap in ordinary (non-special) VMAs.
>>
>> [1] https://lore.kernel.org/r/[email protected]
> 
> Are we sure about this?

Yes, I don't think relaxing this for drivers to use it on VM_MIXEDMAP is
a problem.

> 
> This whole function seems like a hack to support drivers that are not
> using an address_space.

I assume, then using
unmap_mapping_folio()/unmap_mapping_pages()/unmap_mapping_range() instead.

> 
> I say that as one of the five driver authors who have made this
> mistake.
> 
> The locking to safely use this function is really hard to do properly,
> IDK if binder can shift to use address_space ??
I cannot really tell.

Skimming over the code, it looks like it really always handles "single
VMA" stuff ("Since a binder_alloc can only be mapped once, we ensure the
vma corresponds to this mapping by checking whether the binder_alloc is
still mapped"), which makes the locking rather trivial.

It does seem to mostly allocate/free pages in a single VMA, where I
think the existing usage of zap_vma_range() makes sense.

So I'm not sure if using address_space would really be an improvement there.

Having that said, maybe binder folks can be motivated to look into that.
But I would consider that future work.

-- 
Cheers,

David