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

On 9/7/26 16:36, Mike Rapoport wrote:

On Mon, Sep 07, 2026 at 01:18:42PM +0200, David Hildenbrand (Arm) wrote:

quoted

On 9/7/26 08:03, Mike Rapoport wrote:

quoted

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@kernel.org/ (local)

Now that x86 CPA is nearly fixed, I can look into the next iteration.

quoted

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