* 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 [not found] ` <20251114182956.GD2566209@ax162> @ 2025-11-14 18:54 ` Matthew Wilcox 2025-11-14 19:18 ` Nathan Chancellor 0 siblings, 1 reply; 3+ 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] 3+ 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 ` [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 Matthew Wilcox @ 2025-11-14 19:18 ` Nathan Chancellor 2025-11-14 19:39 ` David Hildenbrand (Red Hat) 0 siblings, 1 reply; 3+ 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] 3+ 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; 3+ 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] 3+ messages in thread
end of thread, other threads:[~2025-11-14 19:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <202511141140.LrrRrtIv-lkp@intel.com>
[not found] ` <20251114182956.GD2566209@ax162>
2025-11-14 18:54 ` [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 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).