* [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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).