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

[Jan Polensky]

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:
---8<--- snip ---8<---
> > > I wonder if the following would work:
> > >
> > >
> > > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> > > index 65db9349f9053..56b82e116cb79 100644
> > > --- a/include/linux/gfp_types.h
> > > +++ b/include/linux/gfp_types.h
> > > @@ -47,7 +47,9 @@ enum {
> > >          ___GFP_HARDWALL_BIT,
> > >          ___GFP_THISNODE_BIT,
> > >          ___GFP_ACCOUNT_BIT,
> > > +#ifdef __HAVE_ARCH_TAG_CLEAR_HIGHPAGE
> > >          ___GFP_ZEROTAGS_BIT,
> > > +#endif
> > >   #ifdef CONFIG_KASAN_HW_TAGS
> > >          ___GFP_SKIP_ZERO_BIT,
> > >          ___GFP_SKIP_KASAN_BIT,
> > > @@ -85,7 +87,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)
> > >
> > >
> > > Likely we'd have to make __HAVE_ARCH_TAG_CLEAR_HIGHPAGE a proper
> > > kconfig option.
> > >
> > >
> > > Then we could turn the default implementation of
> > > tag_clear_highpage() into a BUILD_BUG.
> > >
> > I'd like to suggest to keep the enum untouched and only use the second
> > part of your suggestion.
>
> Why? We also do that for CONFIG_KASAN_HW_TAGS, CONFIG_LOCKDEP and
> CONFIG_SLAB_OBJ_EXT.
If we remove the enum entry, we’d also need to update mmflags.h because
the trace macros reference it.
Enums are compile-time only, so they don’t affect the generated binary.
My thought was to keep the enum list as it is and just apply the second
part of your suggestion.
That way, the trace definitions stay consistent without extra changes.
Just an idea, happy to go with whatever you prefer.
>
> > 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.
>