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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 11.11.25 11:44, Jan Polensky wrote:
> 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.

I think we'd remove the enum value as well, because then there is no way 
it could accidentally be reused.

And yes, as you correctly state we'll have to update mmflags as well 
like we did for CONFIG_KASAN_HW_TAGS etc.
-- 
Cheers

David