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

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

On 11.11.25 13:27, David Hildenbrand (Red Hat) wrote:
> 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.

/me realizing that my mail client decided to use yet another mail alias, 
I hope I have it fixed now such that everything is sent from my 
kernel.org account ...

-- 
Cheers

David