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

On Tue, Sep 08, 2026 at 12:38:44PM +0200, David Hildenbrand (Arm) wrote:

On 9/3/26 11:28, Mike Rapoport (Microsoft) wrote:

quoted

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@kernel.org>
---

In general, LGTM.

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

Just like other set_memory, it bails out in the middle if anything bad
happens.
 

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?

There is no rollback in any of set_memory implementations. It's up to the
callers to cleanup the mess afterwards.
 

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

I believe it's more in the scope of  "arch, mm: create a generic
set_memory/change_page_attr core" [1] work than this patchset.

I can write (or maybe even slop ;) ) a doc about set_memory/set_direct_map,
but I wouldn't want to hold this because there's not set_memory
documentation.

[1] https://lore.kernel.org/all/20260721-generic-set-memory-v0-1-v1-0-2c1fc62306b3@kernel.org (local)
 

-- 
Cheers,

David

-- 
Sincerely yours,
Mike.