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

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

[Matthew Wilcox]

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.

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

[Nathan Chancellor]

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

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

[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