[PATCH 1/6] set_memory: add number of pages parameter to set_direct_map APIs

[Mike Rapoport]

On Mon, Aug 17, 2026 at 02:10:39PM +0200, Brendan Jackman wrote:
> On Sun Aug 16, 2026 at 12:59 PM CEST, Mike Rapoport (Microsoft) wrote:
> > When set_direct_map APIs were introduced by the commit d253ca0c3865
> > ("x86/mm/cpa: Add set_direct_map_*() functions") the single page
> > parameter made sense because the initial callers (vmalloc and
> > hibernation) had sets of unsorted struct pages that required changes of
> > their mappings in the direct map.
> >
> > Since there is an increasing demand for direct map manipulation and it
> > is also desirable to be able to update larger physically contiguous
> > mappings, for example an entire large folio, extend set_direct_map APIs
> > to receive number of pages parameter.
> >
> > As there is still only a handful of callers, change the existing
> > functions directly and update all the call sites rather than adding
> > wrappers for single page case.
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt at kernel.org>
> 
> I think if we add this arg we also need to specify how the
> implementations are supposed to behave when they fail midway?

This is the same as set_memory, I don't think it deserves a special care
right now.

> IIUC the incumbent answer for stuff like this is:
> 
> - The implementation might leave partial modifications behind when it
>   fails. The caller needs to deal with that.
> 
> - ... But, that's gonna be due to allocation failure. So the caller can
>   just do the inverse operation in the failure path as a cleanup, and
>   assume that inverse operation succeeds since the pagetables are
>   already allocated up to the failure point.
> 
> I guess it's worth making that a sort of explicit contract since it
> makes certain implementation details load-bearing, e.g. I think...
> 
> - It forces the pagetable update algorithm to work in a fixed order.
> 
> - it forbids us to e.g. merge PTEs into a PMD if the region might be
>   pending such a cleanup, since it would force that cleanup to
>   reallocate a PTE table.

I'd leave the load-bearing parts for now ;-)

I'm going to resend the patches that generalise CPA and I'll add some docs
to that set.

[1] https://lore.kernel.org/linux-mm/20260721-generic-set-memory-v0-1-v1-0-2c1fc62306b3@kernel.org/

-- 
Sincerely yours,
Mike.