* [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0
@ 2025-11-14 6:46 kernel test robot
2025-11-14 18:29 ` Nathan Chancellor
0 siblings, 1 reply; 5+ messages in thread
From: kernel test robot @ 2025-11-14 6:46 UTC (permalink / raw)
To: David Hildenbrand (Red Hat)
Cc: llvm, oe-kbuild-all, Andrew Morton, Linux Memory Management List
tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
head: 1c571d1c4c7e042c3c313d1a2058a17848ccebac
commit: 2f6ff71280ffddb27ad7174d24f573e2683870cd [36/283] mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb
config: powerpc-randconfig-002-20251114 (https://download.01.org/0day-ci/archive/20251114/202511141140.LrrRrtIv-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 0bba1e76581bad04e7d7f09f5115ae5e2989e0d9)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251114/202511141140.LrrRrtIv-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511141140.LrrRrtIv-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
4753 | WARN_ON(order > MAX_FOLIO_ORDER);
| ^~~~~~~~~~~~~~~
include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
| ~~~~~~~~~ ^~~~~~
include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
56 | #define SZ_16G _AC(0x400000000, ULL)
| ^~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~~~~~~
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
20 | #define __AC(X,Y) (X##Y)
| ^~~~
<scratch space>:85:1: note: expanded from here
85 | 0x400000000ULL
| ^~~~~~~~~~~~~~
include/asm-generic/bug.h:123:25: note: expanded from macro 'WARN_ON'
123 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
1 warning generated.
--
>> mm/page_alloc.c:6910:54: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
6910 | if (WARN_ON_ONCE((gfp_mask & __GFP_COMP) && order > MAX_FOLIO_ORDER))
| ^~~~~~~~~~~~~~~
include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
| ~~~~~~~~~ ^~~~~~
include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
56 | #define SZ_16G _AC(0x400000000, ULL)
| ^~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~~~~~~
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
20 | #define __AC(X,Y) (X##Y)
| ^~~~
<scratch space>:106:1: note: expanded from here
106 | 0x400000000ULL
| ^~~~~~~~~~~~~~
include/asm-generic/bug.h:111:25: note: expanded from macro 'WARN_ON_ONCE'
111 | int __ret_warn_on = !!(condition); \
| ^~~~~~~~~
1 warning generated.
--
>> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
1263 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
| ^~~~~~~~~~~~~~~~~~
include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
2104 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
| ^~~~~~~~~~~~~~~
include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
| ~~~~~~~~~ ^~~~~~
include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
56 | #define SZ_16G _AC(0x400000000, ULL)
| ^~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~~~~~~
include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
20 | #define __AC(X,Y) (X##Y)
| ^~~~
<scratch space>:39:1: note: expanded from here
39 | 0x400000000ULL
| ^~~~~~~~~~~~~~
1 warning generated.
vim +4753 mm/hugetlb.c
9fee021d15ddd8 Vaishali Thakkar 2016-05-19 4742
d00181b96eb86c Kirill A. Shutemov 2015-11-06 4743 void __init hugetlb_add_hstate(unsigned int order)
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4744 {
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4745 struct hstate *h;
8faa8b077b2cdc Andi Kleen 2008-07-23 4746 unsigned long i;
8faa8b077b2cdc Andi Kleen 2008-07-23 4747
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4748 if (size_to_hstate(PAGE_SIZE << order)) {
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4749 return;
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4750 }
47d38344abd0c7 Aneesh Kumar K.V 2012-07-31 4751 BUG_ON(hugetlb_max_hstate >= HUGE_MAX_HSTATE);
59838b2566f6d0 Frank van der Linden 2023-10-04 4752 BUG_ON(order < order_base_2(__NR_USED_SUBPAGE));
7b4f21f5e0386d David Hildenbrand 2025-09-01 @4753 WARN_ON(order > MAX_FOLIO_ORDER);
47d38344abd0c7 Aneesh Kumar K.V 2012-07-31 4754 h = &hstates[hugetlb_max_hstate++];
667574e873b5f7 Miaohe Lin 2024-07-12 4755 __mutex_init(&h->resize_lock, "resize mutex", &h->resize_key);
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4756 h->order = order;
aca78307bfdaf3 Miaohe Lin 2021-02-24 4757 h->mask = ~(huge_page_size(h) - 1);
8faa8b077b2cdc Andi Kleen 2008-07-23 4758 for (i = 0; i < MAX_NUMNODES; ++i)
8faa8b077b2cdc Andi Kleen 2008-07-23 4759 INIT_LIST_HEAD(&h->hugepage_freelists[i]);
0edaecfab218d7 Aneesh Kumar K.V 2012-07-31 4760 INIT_LIST_HEAD(&h->hugepage_activelist);
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4761 snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB",
c2c3a60a857bfe Miaohe Lin 2022-09-01 4762 huge_page_size(h)/SZ_1K);
8faa8b077b2cdc Andi Kleen 2008-07-23 4763
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4764 parsed_hstate = h;
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4765 }
a3437870160cf2 Nishanth Aravamudan 2008-07-23 4766
:::::: The code at line 4753 was first introduced by commit
:::::: 7b4f21f5e0386dfe02c68c009294d8f26e3c1bad mm/hugetlb: check for unreasonable folio sizes when registering hstate
:::::: TO: David Hildenbrand <david@redhat.com>
:::::: CC: Andrew Morton <akpm@linux-foundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0
2025-11-14 6:46 [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 kernel test robot
@ 2025-11-14 18:29 ` Nathan Chancellor
2025-11-14 18:54 ` Matthew Wilcox
0 siblings, 1 reply; 5+ messages in thread
From: Nathan Chancellor @ 2025-11-14 18:29 UTC (permalink / raw)
To: kernel test robot
Cc: David Hildenbrand (Red Hat), llvm, oe-kbuild-all, Andrew Morton,
Linux Memory Management List
On Fri, Nov 14, 2025 at 02:46:06PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
> head: 1c571d1c4c7e042c3c313d1a2058a17848ccebac
> commit: 2f6ff71280ffddb27ad7174d24f573e2683870cd [36/283] mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb
> config: powerpc-randconfig-002-20251114 (https://download.01.org/0day-ci/archive/20251114/202511141140.LrrRrtIv-lkp@intel.com/config)
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 0bba1e76581bad04e7d7f09f5115ae5e2989e0d9)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251114/202511141140.LrrRrtIv-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202511141140.LrrRrtIv-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
...
> >> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
> 1263 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
> | ^~~~~~~~~~~~~~~~~~
> include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
> 2104 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
> | ^~~~~~~~~~~~~~~
> include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
> 2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
> | ~~~~~~~~~ ^~~~~~
> include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
> 56 | #define SZ_16G _AC(0x400000000, ULL)
> | ^~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/const.h:21:18: note: expanded from macro '_AC'
> 21 | #define _AC(X,Y) __AC(X,Y)
> | ^~~~~~~~~
> include/uapi/linux/const.h:20:20: note: expanded from macro '__AC'
> 20 | #define __AC(X,Y) (X##Y)
> | ^~~~
> <scratch space>:39:1: note: expanded from here
> 39 | 0x400000000ULL
> | ^~~~~~~~~~~~~~
> 1 warning generated.
For the record, this is not a clang specific warning, as it happens when
building the same configuration with GCC:
In file included from include/vdso/const.h:5,
from include/vdso/bits.h:5,
from include/linux/bits.h:5,
from include/linux/ratelimit_types.h:5,
from include/linux/printk.h:9,
from include/asm-generic/bug.h:28,
from arch/powerpc/include/asm/bug.h:116,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:6,
from mm/util.c:2:
mm/util.c: In function 'snapshot_page':
include/uapi/linux/const.h:20:25: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '17179869184' to '0' [-Woverflow]
20 | #define __AC(X,Y) (X##Y)
| ^~~~~~
include/uapi/linux/const.h:21:25: note: in expansion of macro '__AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~
include/linux/sizes.h:56:41: note: in expansion of macro '_AC'
56 | #define SZ_16G _AC(0x400000000, ULL)
| ^~~
include/linux/mm.h:2214:43: note: in expansion of macro 'SZ_16G'
2214 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
| ^~~~~~
include/linux/mm.h:2223:41: note: in expansion of macro 'MAX_FOLIO_ORDER'
2223 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
| ^~~~~~~~~~~~~~~
mm/util.c:1266:23: note: in expansion of macro 'MAX_FOLIO_NR_PAGES'
1266 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
| ^~~~~~~~~~~~~~~~~~
Cheers,
Nathan
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0
2025-11-14 18:29 ` Nathan Chancellor
@ 2025-11-14 18:54 ` Matthew Wilcox
2025-11-14 19:18 ` Nathan Chancellor
0 siblings, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2025-11-14 18:54 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kernel test robot, David Hildenbrand (Red Hat), llvm,
oe-kbuild-all, Andrew Morton, Linux Memory Management List,
linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy
On Fri, Nov 14, 2025 at 11:29:56AM -0700, Nathan Chancellor wrote:
> > >> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
> > 1263 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
> > | ^~~~~~~~~~~~~~~~~~
> > include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
> > 2104 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
> > | ^~~~~~~~~~~~~~~
> > include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
> > 2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
> > | ~~~~~~~~~ ^~~~~~
> > include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
> > 56 | #define SZ_16G _AC(0x400000000, ULL)
> > | ^~~~~~~~~~~~~~~~~~~~~
Clearly this is a 32-bit build, since otherwise a conversion from
"unsigned long long" to "unsigned long" is a NOP. But 32-bit cannot
support 16GB folios!
I say this is a bug in powerpc32's config.
#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE)
#define MAX_FOLIO_ORDER MAX_PAGE_ORDER
...
#else
#define MAX_FOLIO_ORDER PUD_ORDER
(PUD_ORDER is 16GB, so I think this will be what's being picked up)
but the only place the mentions ARCH_HAS_GIGANTIC_PAGE is pretty
clearly dependent on 64bit ...
config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
select ARCH_HAS_GIGANTIC_PAGE
so I'm a bit stuck about how this comes to be. Adding the PPC people
for thoughts.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0
2025-11-14 18:54 ` Matthew Wilcox
@ 2025-11-14 19:18 ` Nathan Chancellor
2025-11-14 19:39 ` David Hildenbrand (Red Hat)
0 siblings, 1 reply; 5+ messages in thread
From: Nathan Chancellor @ 2025-11-14 19:18 UTC (permalink / raw)
To: Matthew Wilcox
Cc: kernel test robot, David Hildenbrand (Red Hat), llvm,
oe-kbuild-all, Andrew Morton, Linux Memory Management List,
linuxppc-dev, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy
On Fri, Nov 14, 2025 at 06:54:47PM +0000, Matthew Wilcox wrote:
> On Fri, Nov 14, 2025 at 11:29:56AM -0700, Nathan Chancellor wrote:
> > > >> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
> > > 1263 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
> > > | ^~~~~~~~~~~~~~~~~~
> > > include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
> > > 2104 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
> > > | ^~~~~~~~~~~~~~~
> > > include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
> > > 2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
> > > | ~~~~~~~~~ ^~~~~~
> > > include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
> > > 56 | #define SZ_16G _AC(0x400000000, ULL)
> > > | ^~~~~~~~~~~~~~~~~~~~~
>
> Clearly this is a 32-bit build, since otherwise a conversion from
> "unsigned long long" to "unsigned long" is a NOP. But 32-bit cannot
> support 16GB folios!
>
> I say this is a bug in powerpc32's config.
>
> #if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE)
> #define MAX_FOLIO_ORDER MAX_PAGE_ORDER
> ...
> #else
> #define MAX_FOLIO_ORDER PUD_ORDER
>
> (PUD_ORDER is 16GB, so I think this will be what's being picked up)
>
> but the only place the mentions ARCH_HAS_GIGANTIC_PAGE is pretty
> clearly dependent on 64bit ...
>
> config PPC_RADIX_MMU
> bool "Radix MMU Support"
> depends on PPC_BOOK3S_64
> select ARCH_HAS_GIGANTIC_PAGE
>
> so I'm a bit stuck about how this comes to be. Adding the PPC people
> for thoughts.
Note that the original report is against mm-unstable and flags
https://git.kernel.org/akpm/mm/c/c3f81a41ba6f93693d208edde08ce2b0da21c645
https://lore.kernel.org/20251112145632.508687-1-david@kernel.org/
in mm-hotfixes-unstable as the problematic change. This configuration ends up
with
$ rg -N 'HAVE_GIGANTIC|HUGETLB|PPC_8xx' .config
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_PPC_8xx=y
CONFIG_HAVE_GIGANTIC_FOLIOS=y
CONFIG_ARCH_SUPPORTS_HUGETLBFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
config PPC_8xx
bool "Freescale 8xx"
select ARCH_SUPPORTS_HUGETLBFS
select FSL_SOC
select PPC_KUEP
select HAVE_ARCH_VMAP_STACK
select HUGETLBFS
which may indicate a bug in either selecting ARCH_HAS_GIGANTIC_PAGE in
this case or the logic of HAVE_GIGANTIC_FOLIOS in that change?
Cheers,
Nathan
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0
2025-11-14 19:18 ` Nathan Chancellor
@ 2025-11-14 19:39 ` David Hildenbrand (Red Hat)
0 siblings, 0 replies; 5+ messages in thread
From: David Hildenbrand (Red Hat) @ 2025-11-14 19:39 UTC (permalink / raw)
To: Nathan Chancellor, Matthew Wilcox
Cc: kernel test robot, llvm, oe-kbuild-all, Andrew Morton,
Linux Memory Management List, linuxppc-dev, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy
On 14.11.25 20:18, Nathan Chancellor wrote:
> On Fri, Nov 14, 2025 at 06:54:47PM +0000, Matthew Wilcox wrote:
>> On Fri, Nov 14, 2025 at 11:29:56AM -0700, Nathan Chancellor wrote:
>>>>>> mm/util.c:1263:16: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 [-Wconstant-conversion]
>>>> 1263 | if (ps->idx < MAX_FOLIO_NR_PAGES) {
>>>> | ^~~~~~~~~~~~~~~~~~
>>>> include/linux/mm.h:2104:36: note: expanded from macro 'MAX_FOLIO_NR_PAGES'
>>>> 2104 | #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER)
>>>> | ^~~~~~~~~~~~~~~
>>>> include/linux/mm.h:2095:36: note: expanded from macro 'MAX_FOLIO_ORDER'
>>>> 2095 | #define MAX_FOLIO_ORDER get_order(SZ_16G)
>>>> | ~~~~~~~~~ ^~~~~~
>>>> include/linux/sizes.h:56:19: note: expanded from macro 'SZ_16G'
>>>> 56 | #define SZ_16G _AC(0x400000000, ULL)
>>>> | ^~~~~~~~~~~~~~~~~~~~~
>>
>> Clearly this is a 32-bit build, since otherwise a conversion from
>> "unsigned long long" to "unsigned long" is a NOP. But 32-bit cannot
>> support 16GB folios!
>>
>> I say this is a bug in powerpc32's config.
>>
>> #if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE)
>> #define MAX_FOLIO_ORDER MAX_PAGE_ORDER
>> ...
>> #else
>> #define MAX_FOLIO_ORDER PUD_ORDER
>>
>> (PUD_ORDER is 16GB, so I think this will be what's being picked up)
>>
>> but the only place the mentions ARCH_HAS_GIGANTIC_PAGE is pretty
>> clearly dependent on 64bit ...
>>
>> config PPC_RADIX_MMU
>> bool "Radix MMU Support"
>> depends on PPC_BOOK3S_64
>> select ARCH_HAS_GIGANTIC_PAGE
>>
>> so I'm a bit stuck about how this comes to be. Adding the PPC people
>> for thoughts.
>
> Note that the original report is against mm-unstable and flags
>
> https://git.kernel.org/akpm/mm/c/c3f81a41ba6f93693d208edde08ce2b0da21c645
> https://lore.kernel.org/20251112145632.508687-1-david@kernel.org/
>
> in mm-hotfixes-unstable as the problematic change. This configuration ends up
> with
>
> $ rg -N 'HAVE_GIGANTIC|HUGETLB|PPC_8xx' .config
> # CONFIG_CGROUP_HUGETLB is not set
> CONFIG_PPC_8xx=y
> CONFIG_HAVE_GIGANTIC_FOLIOS=y
> CONFIG_ARCH_SUPPORTS_HUGETLBFS=y
> CONFIG_HUGETLBFS=y
> CONFIG_HUGETLB_PAGE=y
>
> config PPC_8xx
> bool "Freescale 8xx"
> select ARCH_SUPPORTS_HUGETLBFS
> select FSL_SOC
> select PPC_KUEP
> select HAVE_ARCH_VMAP_STACK
> select HUGETLBFS
>
> which may indicate a bug in either selecting ARCH_HAS_GIGANTIC_PAGE in
> this case or the logic of HAVE_GIGANTIC_FOLIOS in that change?
God how I HATE that hugetlb crap at this point. So much wasted time.
Likely, for 32bit builds we should cap it at 1 GiB, which I think is the
32bit maximum hugetlb folios size on ppc actually is.
--
Cheers
David
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-11-14 19:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-14 6:46 [akpm-mm:mm-unstable 36/283] mm/hugetlb.c:4753:18: warning: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 17179869184 to 0 kernel test robot
2025-11-14 18:29 ` Nathan Chancellor
2025-11-14 18:54 ` Matthew Wilcox
2025-11-14 19:18 ` Nathan Chancellor
2025-11-14 19:39 ` David Hildenbrand (Red Hat)
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.