Re: [PATCH v7 1/3] mm: make persistent huge zero folio read-only

[David Hildenbrand (Arm)]

On 9/7/26 16:36, Mike Rapoport wrote:
> On Mon, Sep 07, 2026 at 01:18:42PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/7/26 08:03, Mike Rapoport wrote:
>>> Hi Xueyuan,
>>>
>>>
>>> And I believe this is an historical artifact rather than necessity. For
>>> configurations that allow set_direct_map on arm64, change_memory_common can
>>> update direct map too, it just need to be implemented there.
>>>
>>
>> Are we sure the other architectures do what we want in their set_memory_ro?
> 
> It's a zoo right now :(

Yeah, that's why I'm asking :)

> Although most of them do.
> 
> But we need to sort it out anyway because of increasingly growing demand
> for modifications of the kernel page tables.

The question really is whether we want to use a single interface for all page
tables.

I quite like a page-based directmap interface. Other page table areas are not
necessarily page-based. It also expresses which types of operations we expect on
the direct map.

One could, of course, use set_memory_ro() internally to implement
set_direct_map_ro() (and similarly for other variants); but at least
set_direct_map_*() would have clear, well documented semantics.

> 
> I started something here:
> https://lore.kernel.org/linux-mm/20260721-generic-set-memory-v0-1-v1-0-2c1fc62306b3@xxxxxxxxxx/
> 
> Now that x86 CPA is nearly fixed, I can look into the next iteration.
> 
>> Having a dedicated set_direct_map_ro() with clear (documented ;)) semantics does
>> not sound too crazy to me.
> 
> It's not too crazy, no.
> 
> Still making arm64 more aligned with x86 and other arches that update the
> direct/linear map in the set_memory_ro() seem a good thing on it's own.

Right, but I'd much rather user set_memory_ro() later to implement
set_direct_map_ro() [initially on architectures where we made sure that it
actually does what we expect? later maybe generically]

-- 
Cheers,

David