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

[Xueyuan Chen]

On Fri, Jun 19, 2026 at 01:09:09PM +0200, David Hildenbrand (Arm) wrote:

Hi, David

[...]

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

After talking with Lance, we're leaning toward a direct-map helper:

  set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)

Contract should be pretty explicit: direct/linear map only, no alias
handling, no TLB flush. If a caller needs stale entries gone, it has
to flush itself.

Huge zero folio only uses this early during boot so far, so noflush
should be OK. Will document that.

Thanks,
Xueyuan