Re: [PATCH v3 11/26] x86/mm: introduce the mermap

["Brendan Jackman" <brendan.jackman@linux.dev>]

On Sun Aug 2, 2026 at 5:40 PM BST, Mike Rapoport wrote:
...
>> +
>> +VISIBLE_IF_KUNIT void __mermap_put(struct mm_struct *mm, struct mermap_alloc *alloc)
>> +{
>> +	unsigned long size = PAGE_ALIGN(alloc->end - alloc->base);
>> +
>> +	__apply_to_page_range(mm, alloc->base, size, set_unmapped_pte,
>> +			      NULL, PGRANGE_CREATE | PGRANGE_NOLOCK);
>> +
>
> Sorry if I missed that in previous discussions.
>
> __apply_to_page_range() acts only on PTE mappings, and looking forward I
> presume we'd want PMD and maybe event PUD mappings in guest_memfd and
> subsequently in mermap.

Yeah.

> We anyway have a ton of page table walkers, so maybe it'll make sense to
> add yet another one rather than adjust __apply_to_page_range() to the
> mermap needs?

Yeah... I would really like to avoid creating another. This was
basically the topic of my last LSF/MM/BPF session that I pivoted
away from at the last minute coz I just don't really have a clear idea
of how to proceed.

I feel like maybe the way forward is to try and pick one and slowly
steer it towards being generic enough to subsume another one? Like maybe
we could target incrementally converging the set_memory and
__apply_to_page_range implementations or something...

> Or maybe there's a suitable walk_ API in mm/pagewalk.c?

I think that code is all pretty tailored towards _inspecting_ instead of
modifying.