[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

[David Hildenbrand (Red Hat)]

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