[PATCH] arm64: mte: Do not flag the zero page as PG_mte_tagged

[Lance Yang]

On 2025/9/24 20:31, Catalin Marinas wrote:
> Commit 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the
> zero page") attempted to fix ptrace() reading of tags from the zero page
> by marking it as PG_mte_tagged during cpu_enable_mte(). The same commit
> also changed the ptrace() tag access permission check to the VM_MTE vma
> flag while turning the page flag test into a WARN_ON_ONCE().
> 
> Attempting to set the PG_mte_tagged flag early with
> CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled may either hang (after commit
> d77e59a8fccd "arm64: mte: Lock a page for MTE tag initialisation") or
> have the flags cleared later during page_alloc_init_late(). In addition,
> pages_identical() -> memcmp_pages() will reject any comparison with the
> zero page as it is marked as tagged.
> 
> Partially revert the above commit to avoid setting PG_mte_tagged on the
> zero page. Update the __access_remote_tags() warning on untagged pages
> to ignore the zero page since it is known to have the tags initialised.
> 
> Note that all user mapping of the zero page are marked as pte_special().
> The arm64 set_pte_at() will not call mte_sync_tags() on such pages, so
> PG_mte_tagged will remain cleared.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Fixes: 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page")
> Reported-by: Gergely Kovacs <Gergely.Kovacs2 at arm.com>
> Cc: <stable at vger.kernel.org> # 5.10.x
> Cc: Will Deacon <will at kernel.org>
> Cc: David Hildenbrand <david at redhat.com>
> Cc: Lance Yang <lance.yang at linux.dev>
> ---
> 
> For reference, discussion on page merging here:
> 
> https://lore.kernel.org/r/aNKJ5glToE4hMhWA@arm.com

Cool. LGTM.
Acked-by: Lance Yang <lance.yang at linux.dev>

> 
> The deferred struct page init problem was reported by Gergely offline.
> 
> Given that we've had this bug for over four years and it was only
> recently noticed, I think we should merge it at -rc1, give it a bit more
> time in -next in case it breaks anything (not likely but you never know,
> MTE interaction with the mm code is always surprising ;)).
> 
>   arch/arm64/kernel/cpufeature.c | 10 +++++++---
>   arch/arm64/kernel/mte.c        |  2 +-
>   2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index ef269a5a37e1..3e9d1aa37bbf 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2408,17 +2408,21 @@ static void bti_enable(const struct arm64_cpu_capabilities *__unused)
>   #ifdef CONFIG_ARM64_MTE
>   static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
>   {
> +	static bool cleared_zero_page = false;
> +
>   	sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ATA | SCTLR_EL1_ATA0);
>   
>   	mte_cpu_setup();
>   
>   	/*
>   	 * Clear the tags in the zero page. This needs to be done via the
> -	 * linear map which has the Tagged attribute.
> +	 * linear map which has the Tagged attribute. Since this page is
> +	 * always mapped as pte_special(), set_pte_at() will not attempt to
> +	 * clear the tags or set PG_mte_tagged.
>   	 */
> -	if (try_page_mte_tagging(ZERO_PAGE(0))) {
> +	if (!cleared_zero_page) {
> +		cleared_zero_page = true;
>   		mte_clear_page_tags(lm_alias(empty_zero_page));
> -		set_page_mte_tagged(ZERO_PAGE(0));
>   	}
>   
>   	kasan_init_hw_tags_cpu();
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index e5e773844889..63aed49ac181 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -460,7 +460,7 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr,
>   		if (folio_test_hugetlb(folio))
>   			WARN_ON_ONCE(!folio_test_hugetlb_mte_tagged(folio));
>   		else
> -			WARN_ON_ONCE(!page_mte_tagged(page));
> +			WARN_ON_ONCE(!page_mte_tagged(page) && !is_zero_page(page));
>   
>   		/* limit access to the end of the page */
>   		offset = offset_in_page(addr);