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

[Xueyuan Chen]

On Mon, Jul 27, 2026 at 11:35:30AM -0700, Andrew Morton wrote:
>On Mon, 27 Jul 2026 22:34:23 +0800 Xueyuan Chen <xueyuan.chen21@xxxxxxxxx> wrote:
>
>> The persistent huge zero folio is shared globally and should stay zero
>> after initialization. As Jann Horn pointed out[1], kernel bugs have ended
>> up writing to pages that were meant to be read-only, including in
>> security-sensitive cases. Making the folio read-only in the direct map
>> turns such writes into faults instead of silent zero-page corruption.
>> 
>> This series adds set_direct_map_ro_noflush() so mm code can make a
>> direct-map range read-only, then uses it for the persistent huge zero
>> folio. The helper is direct-map specific, takes an address-based range as
>> discussed for set_direct_map* helpers[2], and leaves TLB invalidation to
>> the caller.
>
>Thanks.  AI review asked about a few things, some pre-existing.  Includes
>a possible pre-existing ARM barrier issue in arch/arm64/mm/pageattr.c
>	https://sashiko.dev/#/patchset/20260727143426.1077133-1-xueyuan.chen21@xxxxxxxxx
>

Hi Andrew,

Thanks. The highmem case is valid. A highmem folio has no permanent
direct-map mapping, so v6 will skip the permission update and TLB flush
in that case.

The huge_zero_pfn race is addressed by Lorenzo's mm-hotfixes series:

https://lore.kernel.org/r/20260728-fix-refcounted-huge-zero-v1-0-3f261f5447b4@xxxxxxxxxx

I don't think the MTE report needs a change. Commit 1d0cb4c8864a
("arm64: mte: Ensure the cleared tags are visible before setting the
PTE") added the smp_wmb() specifically for this ordering.

I'll send v6 shortly.

Thanks
Xueyuan