Re: [RFC PATCH 0/3] make persistent huge zero folio read-only

[Lance Yang <lance.yang@linux.dev>]

Hi Dave,

Sorry for the late reply.

On Wed, May 27, 2026 at 08:58:38AM -0700, Dave Hansen wrote:
>On 5/26/26 20:56, Xueyuan chen wrote:
>> The motivation comes from Jann Horn's read-only zero page work[1] and the
>> follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has
>> had bugs, including security bugs, where pages taken with read-only
>> semantics were later written to.
>
>My overall concern with this is that it's just a code hack for the huge
>zero page and nothing else. It's a total one-off.

Fair point. I was trying to keep the first version simple, so I
special-cased the persistent huge zero folio. But agreed, the arch side
should not grow a huge-zero-folio-only hook :)

>I think you need to make the case here that the huge zero page truly is
>a special snowflake and deserves a one-off special snowflake solution.
>Because it doesn't seem *that* crazy that there are more things that the
>kernel dynamically allocates that it wants to keep read only.
>
>Maybe there aren't many things that get mapped to userspace like this.
>But the case needs to get made either way.

For RFC v2, I think we should make the arch hook generic, probably
arch_make_folio_readonly(), with a weak default implementation. The
persistent huge zero folio would just be the first user.

But even with a generic helper, we still need to be careful about the
model. I see two possible ones:

1) Treat "read-only in the direct map" as real folio state. Then core MM
has to know about it and carry or clear that state in paths like
migration and freeing. It also makes the possible direct-map split / TLB
cost a more general MM issue, not just a cost tied to one caller ...

2) Only use the helper for folios with a simple lifetime: allocated once,
not migrated, not freed, and not written after they are made read-only.

I'd start with 2. Keeps the arch API generic, but avoids teaching core
MM a new folio state before we have a user that really needs that. The
persistent huge zero folio still works fine with that model. It just
becomes the first user instead of the special case :)

Thoughts?

Cheers, Lance