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

[Brendan Jackman]

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?

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.