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

[Mike Rapoport <rppt@kernel.org>]

On Tue, Sep 08, 2026 at 12:38:44PM +0200, David Hildenbrand (Arm) wrote:
> 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@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
 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.