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

[David Hildenbrand (Arm)]

On 9/3/26 11:28, 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>
> ---
In general, LGTM.

But regarding semantics, is it well defined what happens when an update fails
halfway through an operation?

I'd assume such a case cannot currently get triggered, but there is no
documentation on what's supported and what's not. Or is there?

Imagine someone performing an update on an area that partially spans two PMDs.
While splitting and updating the first PMD could succeed, splitting the second
PMD could fail. What would be the end result? Rollback? Does the caller have to
clean up?

I'd appreciate if we could add proper documentation with expected semantics.

-- 
Cheers,

David