Message-ID: <0b007374-1058-487c-8033-4f0d2830dc89@kernel.org>
Date: Thu, 4 Dec 2025 07:17:06 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Shuah Khan <skhan@...uxfoundation.org>, akpm@...ux-foundation.org
Cc: maddy@...ux.ibm.com, mpe@...erman.id.au, npiggin@...il.com,
 christophe.leroy@...roup.eu, lorenzo.stoakes@...cle.com,
 Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
 mhocko@...e.com, masahiroy@...nel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with
 hugetlb"

Hi,

On 12/4/25 03:33, Shuah Khan wrote:
> This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98.

That was supposed to fix powerpc handling though. So I think we have to
understand what is happening here.

> 
> Enabling HAVE_GIGANTIC_FOLIOS broke kernel build and git clone on two
> systems. git fetch-pack fails when cloning large repos and make hangs
> or errors out of Makefile.build with Error: 139. These failures are
> random with git clone failing after fetching 1% of the objects, and
> make hangs while compiling random files.

On which architecture do we see these issues and with which kernel configs?
Can you share one?

> 
> The blow is is one of the git clone failures:
> 
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_6.19
> Cloning into 'linux_6.19'...
> remote: Enumerating objects: 11173575, done.
> remote: Counting objects: 100% (785/785), done.
> remote: Compressing objects: 100% (373/373), done.
> remote: Total 11173575 (delta 534), reused 505 (delta 411), pack-reused 11172790 (from 1)
> Receiving objects: 100% (11173575/11173575), 3.00 GiB | 7.08 MiB/s, done.
> Resolving deltas: 100% (9195212/9195212), done.
> fatal: did not receive expected object 0002003e951b5057c16de5a39140abcbf6e44e50
> fatal: fetch-pack: invalid index-pack output

If I would have to guess, these symptoms match what we saw between commit
adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
and commit 5bebe8de1926 ("mm/huge_memory: Fix initialization of huge zero folio").

5bebe8de1926 went into v6.18-rc7.

Just to be sure, are you sure we were able to reproduce this issue with a
v6.18-rc7 or even v6.18 that contains 5bebe8de1926?

Bisecting might give you wrong results, as the problems of adfb6609c680 do not
reproduce reliably.


The confusing bit is that MAX_FOLIO_ORDER is mostly used for warnings:

$ git grep MAX_FOLIO_ORDER
include/linux/mm.h:#define MAX_FOLIO_ORDER              MAX_PAGE_ORDER
include/linux/mm.h:#define MAX_FOLIO_ORDER              PFN_SECTION_SHIFT
include/linux/mm.h:#define MAX_FOLIO_ORDER              get_order(IS_ENABLED(CONFIG_64BIT) ? SZ_16G : SZ_1G)
include/linux/mm.h:#define MAX_FOLIO_ORDER              PUD_ORDER
include/linux/mm.h:#define MAX_FOLIO_NR_PAGES   (1UL << MAX_FOLIO_ORDER)
mm/hugetlb.c:   BUILD_BUG_ON_INVALID(HUGETLB_PAGE_ORDER > MAX_FOLIO_ORDER);
mm/hugetlb.c:   WARN_ON(order > MAX_FOLIO_ORDER);
mm/internal.h:  VM_WARN_ON_ONCE(order > MAX_FOLIO_ORDER);
mm/memremap.c:  if (WARN_ONCE(pgmap->vmemmap_shift > MAX_FOLIO_ORDER,
mm/page_alloc.c:        if (WARN_ON_ONCE((gfp_mask & __GFP_COMP) && order > MAX_FOLIO_ORDER))


And MAX_FOLIO_NR_PAGES (derived from MAX_FOLIO_ORDER) is only used in a debug helper

$ git grep MAX_FOLIO_NR_PAGES
include/linux/mm.h:#define MAX_FOLIO_NR_PAGES   (1UL << MAX_FOLIO_ORDER)
mm/util.c:      if (ps->idx < MAX_FOLIO_NR_PAGES) {


> 
> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
> ---
>   arch/powerpc/Kconfig                   |  1 -
>   arch/powerpc/platforms/Kconfig.cputype |  1 +
>   include/linux/mm.h                     | 13 +++----------
>   mm/Kconfig                             |  7 -------
>   4 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9537a61ebae0..e24f4d88885a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -137,7 +137,6 @@ config PPC
>   	select ARCH_HAS_DMA_OPS			if PPC64
>   	select ARCH_HAS_FORTIFY_SOURCE
>   	select ARCH_HAS_GCOV_PROFILE_ALL
> -	select ARCH_HAS_GIGANTIC_PAGE		if ARCH_SUPPORTS_HUGETLBFS
>   	select ARCH_HAS_KCOV
>   	select ARCH_HAS_KERNEL_FPU_SUPPORT	if PPC64 && PPC_FPU
>   	select ARCH_HAS_MEMBARRIER_CALLBACKS
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 4c321a8ea896..7b527d18aa5e 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -423,6 +423,7 @@ config PPC_64S_HASH_MMU
>   config PPC_RADIX_MMU
>   	bool "Radix MMU Support"
>   	depends on PPC_BOOK3S_64
> +	select ARCH_HAS_GIGANTIC_PAGE
>   	default y
>   	help
>   	  Enable support for the Power ISA 3.0 Radix style MMU. Currently this
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 7c79b3369b82..d16b33bacc32 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2074,7 +2074,7 @@ static inline unsigned long folio_nr_pages(const struct folio *folio)
>   	return folio_large_nr_pages(folio);
>   }
>   
> -#if !defined(CONFIG_HAVE_GIGANTIC_FOLIOS)
> +#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE)
>   /*
>    * We don't expect any folios that exceed buddy sizes (and consequently
>    * memory sections).
> @@ -2087,17 +2087,10 @@ static inline unsigned long folio_nr_pages(const struct folio *folio)
>    * pages are guaranteed to be contiguous.
>    */
>   #define MAX_FOLIO_ORDER		PFN_SECTION_SHIFT
> -#elif defined(CONFIG_HUGETLB_PAGE)
> -/*
> - * There is no real limit on the folio size. We limit them to the maximum we
> - * currently expect (see CONFIG_HAVE_GIGANTIC_FOLIOS): with hugetlb, we expect
> - * no folios larger than 16 GiB on 64bit and 1 GiB on 32bit.
> - */
> -#define MAX_FOLIO_ORDER		get_order(IS_ENABLED(CONFIG_64BIT) ? SZ_16G : SZ_1G)
>   #else
>   /*
> - * Without hugetlb, gigantic folios that are bigger than a single PUD are
> - * currently impossible.
> + * There is no real limit on the folio size. We limit them to the maximum we
> + * currently expect (e.g., hugetlb, dax).
>    */
>   #define MAX_FOLIO_ORDER		PUD_ORDER
>   #endif
> diff --git a/mm/Kconfig b/mm/Kconfig
> index ca3f146bc705..0e26f4fc8717 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -908,13 +908,6 @@ config PAGE_MAPCOUNT
>   config PGTABLE_HAS_HUGE_LEAVES
>   	def_bool TRANSPARENT_HUGEPAGE || HUGETLB_PAGE
>   
> -#
> -# We can end up creating gigantic folio.
> -#
> -config HAVE_GIGANTIC_FOLIOS
> -	def_bool (HUGETLB_PAGE && ARCH_HAS_GIGANTIC_PAGE) || \
> -		 (ZONE_DEVICE && HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
> -
>   # TODO: Allow to be enabled without THP
>   config ARCH_SUPPORTS_HUGE_PFNMAP
>   	def_bool n


-- 
Cheers

David

Powered by blists - more mailing lists