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

[David Hildenbrand (Arm)]

On 6/19/26 04:55, Xueyuan Chen wrote:
> On Thu, Jun 18, 2026 at 02:36:25PM +0200, David Hildenbrand (Arm) wrote:
> 
> Hi, David
> 
> [...]
> 
>> Best to wait for some feedback.
> 
> Sure.
> 
>> I do wonder whether we want to pass an address instead of a page.
>>
>> https://lore.kernel.org/r/20260410151746.61150-2-kalyazin@xxxxxxxxxx
>>
>> Wants to convert existing ones as well.
>>
>> That would imply that the caller must check for highmem.
>>
>> But then, we could just use existing set_memory_ro(), right?
>>
> 
> Agreed. Passing an address and reusing the existing set_memory_ro() 
> definitely makes things simpler.
> 
> However, there is an arm64 specific limitation:
> currently, the set_memory_r* api on arm64 only support the vmap
> region and do not handle linear map addresses.
> 
> If we go this route, should I extend the arm64 set_memory_r*
> implementation in the next version? The plan would be to make it check 
> for the bblm2 feature and modify the linear map PTEs accordingly.
> What do you think?

Good point! It's not really clear on which ranges set_memory*() is supposed to
work ...

arm64 only works on vmalloc/vmap, x86 and riscv on ordinary directmap ... what a
mess.

Having a new direct-map specific function with clear semantics might indeed
avoid even messing with that.

So, yeah, given that we have

	set_direct_map_invalid_noflush
	set_direct_map_default_noflush
	set_direct_map_valid_noflush

Let's add a

	set_direct_map_ro()

Or (my preference)

	change_direct_map_ro()

But given the existing naming scheme ... maybe just set_direct_map_ro() and
we'll clean this up another day.


Now, should there also be a "_noflush" in there, or who is supposed to flush the
TLB (or don't we flush at all, because it's used early during boot so far)?

In any case, for this function we should add excessive documentation and define
clear semantics.

-- 
Cheers,

David