All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Red Hat)" <davidhildenbrandkernel@gmail.com>
To: Jan Polensky <japo@linux.ibm.com>, catalin.marinas@arm.com
Cc: akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org,
	linux-mm@kvack.org, will@kernel.org
Subject: Re: [PATCH] mm/huge_memory: restrict __GFP_ZEROTAGS to HW tagging architectures
Date: Mon, 10 Nov 2025 10:53:33 +0100	[thread overview]
Message-ID: <fbca7868-6f68-4b98-a2f2-e39eb46b7f12@gmail.com> (raw)
In-Reply-To: <aRG05VS-IIxV2y_C@li-276bd24c-2dcc-11b2-a85c-945b6f05615c.ibm.com>

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').
>>>
>>> Restrict the use of __GFP_ZEROTAGS to architectures that support
>>> hardware memory tagging (currently arm64 with MTE or KASAN HW tags).
>>> This avoids unintended side effects on other platforms.
>>>
>>> Fixes: 1579227fe0f0 ("mm/huge_memory: initialise the tags of the huge zero folio")
>>> Link: https://lore.kernel.org/r/20251031170133.280742-1-catalin.marinas@arm.com
>>> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
>>> ---
>>>    mm/huge_memory.c | 9 +++++----
>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index aae283b00857..0c1794656d7a 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -209,14 +209,15 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma,
>>>
>>>    static bool get_huge_zero_folio(void)
>>>    {
>>> +	gfp_t gfp = (GFP_TRANSHUGE | __GFP_ZERO) & ~__GFP_MOVABLE;
>>>    	struct folio *zero_folio;
>>>    retry:
>>>    	if (likely(atomic_inc_not_zero(&huge_zero_refcount)))
>>>    		return true;
>>> -
>>> -	zero_folio = folio_alloc((GFP_TRANSHUGE | __GFP_ZERO | __GFP_ZEROTAGS) &
>>> -				 ~__GFP_MOVABLE,
>>> -			HPAGE_PMD_ORDER);
>>> +#if IS_ENABLED(CONFIG_KASAN_HW_TAGS) || IS_ENABLED(CONFIG_ARM64_MTE)
>>> +	gfp |= __GFP_ZEROTAGS;
>>> +#endif
>>
>> That looks like the wrong approach. If an architecture does not support
>> __GFP_ZEROTAGS it should not trigger anything. __GFP_ZEROTAGS should be ignored.
>>
>> 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.
>>
>> Gah.
>>
>> 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.

> 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.



  reply	other threads:[~2025-11-10  9:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-31 16:57 [PATCH] mm/huge_memory: Initialise the tags of the huge zero folio Catalin Marinas
2025-10-31 17:15 ` David Hildenbrand
2025-11-03 13:32 ` Mark Brown
2025-11-03 14:30   ` Catalin Marinas
2025-11-03 14:41     ` David Hildenbrand (Red Hat)
2025-11-03 15:59       ` Catalin Marinas
2025-11-03 19:29         ` Beleswar Prasad Padhi
2025-11-04  1:05         ` Andrew Morton
2025-11-04  8:52           ` Catalin Marinas
2025-11-04 11:53     ` [PATCH] mm/huge_memory: Initialise the tags of the huge zero Lance Yang
2025-11-08 19:19 ` [PATCH] mm/huge_memory: initialise the tags of the huge zero folio Jan Polensky
2025-11-09  0:42   ` [PATCH] Clarification: please ignore earlier submission Jan Polensky
2025-11-09  0:36 ` [PATCH] mm/huge_memory: restrict __GFP_ZEROTAGS to HW tagging architectures Jan Polensky
2025-11-10  9:09   ` David Hildenbrand (Red Hat)
2025-11-10  9:48     ` Jan Polensky
2025-11-10  9:53       ` David Hildenbrand (Red Hat) [this message]
2025-11-10 15:28         ` Catalin Marinas
2025-11-10 15:55           ` Catalin Marinas
2025-11-22 12:04           ` Balbir Singh
2025-11-24 10:57             ` David Hildenbrand (Red Hat)
2025-11-24 18:08               ` Andrew Morton
2025-11-11 10:44         ` Jan Polensky
2025-11-11 12:27           ` David Hildenbrand (Red Hat)
2025-11-11 12:28             ` David Hildenbrand (Red Hat)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fbca7868-6f68-4b98-a2f2-e39eb46b7f12@gmail.com \
    --to=davidhildenbrandkernel@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=japo@linux.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.