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

[Yang Shi <yang@os.amperecomputing.com>]

On 6/19/26 4:09 AM, David Hildenbrand (Arm) wrote:
> 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@amazon.com
>>>
>>> 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.

arm64 version works on vmalloc/vmap *and* the linear map alias if rodata 
is on (a.k.a. full before). It should be not hard to make it work for 
linear map address (w/o vmalloc/vmap alias). I think we can just follow 
riscv's implementation by doing:

if (vmalloc or vmap address)
     ...
else if (linear map address)
     ...

Thanks,
Yang

>
> 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.
>