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
