Re: [PATCH] mm/huge_memory: restrict __GFP_ZEROTAGS to HW tagging architectures

[Catalin Marinas <catalin.marinas@arm.com>]

On Mon, Nov 10, 2025 at 10:53:33AM +0100, David Hildenbrand (Red Hat) wrote:
> On 10.11.25 10:48, Jan Polensky wrote:
> > On Mon, Nov 10, 2025 at 10:09:31AM +0100, David Hildenbrand (Red Hat) wrote:
> > > On 09.11.25 01:36, Jan Polensky wrote:
> > > > The previous change added __GFP_ZEROTAGS when allocating the huge zero
> > > > folio to ensure tag initialization for arm64 with MTE enabled. However,
> > > > on s390 this flag is unnecessary and triggers a regression
> > > > (observed as a crash during repeated 'dnf makecache').
[...]
> > > I think the problem is that post_alloc_hook() does
> > > 
> > > if (zero_tags) {
> > > 	/* Initialize both memory and memory tags. */
> > > 	for (i = 0; i != 1 << order; ++i)
> > > 		tag_clear_highpage(page + i);
> > > 
> > > 	/* Take note that memory was initialized by the loop above. */
> > > 	init = false;
> > > }
> > > 
> > > And tag_clear_highpage() is a NOP on other architectures.

Hmm, another thing I missed. Sorry about this.

> > Which works by the way for our arch (s390).
> > 
> >   include/linux/gfp_types.h | 4 ++++
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> > index 65db9349f905..c12d8a601bb3 100644
> > --- a/include/linux/gfp_types.h
> > +++ b/include/linux/gfp_types.h
> > @@ -85,7 +85,11 @@ enum {
> >   #define ___GFP_HARDWALL        BIT(___GFP_HARDWALL_BIT)
> >   #define ___GFP_THISNODE        BIT(___GFP_THISNODE_BIT)
> >   #define ___GFP_ACCOUNT     BIT(___GFP_ACCOUNT_BIT)
> > +#ifdef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
> >   #define ___GFP_ZEROTAGS        BIT(___GFP_ZEROTAGS_BIT)
> > +#else
> > +#define ___GFP_ZEROTAGS        0
> > +#endif
> >   #ifdef CONFIG_KASAN_HW_TAGS
> >   #define ___GFP_SKIP_ZERO   BIT(___GFP_SKIP_ZERO_BIT)
> >   #define ___GFP_SKIP_KASAN  BIT(___GFP_SKIP_KASAN_BIT)
> > 
> > This solution would be sufficient from my side, and I would appreciate a
> > quick application if there are no objections.
> 
> As raised, to be sure that __HAVE_ARCH_TAG_CLEAR_HIGHPAGE is always seen
> early in that file, it should likely become a CONFIG_ thing.

I'm fine with either option above but I'll throw one more in the mix:

--------------------8<--------------------------------
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 2312e6ee595f..dcff91533590 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,6 +33,7 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
 						unsigned long vaddr);
 #define vma_alloc_zeroed_movable_folio vma_alloc_zeroed_movable_folio
 
+bool arch_has_tag_clear_highpage(void);
 void tag_clear_highpage(struct page *to);
 #define __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
 
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 125dfa6c613b..318d091db843 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -967,18 +967,13 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
 	return vma_alloc_folio(flags, 0, vma, vaddr);
 }
 
+bool arch_has_tag_clear_highpage(void)
+{
+	return system_supports_mte();
+}
+
 void tag_clear_highpage(struct page *page)
 {
-	/*
-	 * Check if MTE is supported and fall back to clear_highpage().
-	 * get_huge_zero_folio() unconditionally passes __GFP_ZEROTAGS and
-	 * post_alloc_hook() will invoke tag_clear_highpage().
-	 */
-	if (!system_supports_mte()) {
-		clear_highpage(page);
-		return;
-	}
-
 	/* Newly allocated page, shouldn't have been tagged yet */
 	WARN_ON_ONCE(!try_page_mte_tagging(page));
 	mte_zero_clear_page_tags(page_address(page));
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 105cc4c00cc3..7aa56179ccef 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -251,6 +251,11 @@ static inline void clear_highpage_kasan_tagged(struct page *page)
 
 #ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
 
+static inline bool arch_has_tag_clear_highpage(void)
+{
+	return false;
+}
+
 static inline void tag_clear_highpage(struct page *page)
 {
 }
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e4efda1158b2..5ab15431bc06 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1798,7 +1798,8 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
 {
 	bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
 			!should_skip_init(gfp_flags);
-	bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
+	bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS) &&
+		arch_has_tag_clear_highpage();
 	int i;
 
 	set_page_private(page, 0);
--------------------8<--------------------------------

Reasoning: with MTE on arm64, you can't have kasan-tagged pages in the
kernel which are also exposed to user because the tags are shared (same
physical location). The 'zero_tags' initialisation in post_alloc_hook()
makes sense for this behaviour. With virtual tagging (briefly announced
in [1], full specs not public yet), both the user and the kernel can
have their own tags - more like KASAN_SW_TAGS but without the compiler
instrumentation. The kernel won't be able to zero the tags for the user
since they are in virtual space. It can, however, continue to use Kasan
tags even if the pages are mapped in user space. In this case, I'd
rather use the kernel_init_pages() call further down in
post_alloc_hook() than replicating it in tag_clear_highpage(). When we
get to upstreaming virtual tagging (informally vMTE, sometime next
year), I'd like to have a kernel image that supports both, so the
decision on whether to call tag_clear_highpage() will need to be
dynamic.

[1] https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/future-architecture-technologies-poe2-and-vmte

-- 
Catalin