Re: [linux-next:master 3778/4413] include/linux/mmzone.h:1749:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE

[Mike Rapoport <rppt@kernel.org>]

On Wed, Mar 22, 2023 at 03:54:09PM +0800, WANG Xuerui wrote:
> On 2023/3/22 15:42, Mike Rapoport wrote:
> > On Tue, Mar 21, 2023 at 10:59:36AM +0800, Huacai Chen wrote:
> > > Hi, all,
> > > 
> > > On Mon, Mar 20, 2023 at 11:56 PM Kirill A. Shutemov
> > > <kirill@shutemov.name> wrote:
> > > > 
> > > > On Mon, Mar 20, 2023 at 04:06:33PM +0800, kernel test robot wrote:
> > > > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > > > > head:   73f2c2a7e1d2b31fdd5faa6dfa151c437a6c0a5a
> > > > > commit: af8daebdbc0833b8095767ccef7ddce55e9fdf32 [3778/4413] mm, treewide: redefine MAX_ORDER sanely
> > > > > config: loongarch-buildonly-randconfig-r003-20230320 (https://download.01.org/0day-ci/archive/20230320/202303201615.Qfu18nWV-lkp@intel.com/config)
> > > > > compiler: loongarch64-linux-gcc (GCC) 12.1.0
> > > > > reproduce (this is a W=1 build):
> > > > >          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > > >          chmod +x ~/bin/make.cross
> > > > >          # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=af8daebdbc0833b8095767ccef7ddce55e9fdf32
> > > > >          git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > > >          git fetch --no-tags linux-next master
> > > > >          git checkout af8daebdbc0833b8095767ccef7ddce55e9fdf32
> > > > >          # save the config file
> > > > >          mkdir build_dir && cp config build_dir/.config
> > > > >          COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch olddefconfig
> > > > >          COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch prepare
> > > > > 
> > > > > If you fix the issue, kindly add following tag where applicable
> > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > | Link: https://lore.kernel.org/oe-kbuild-all/202303201615.Qfu18nWV-lkp@intel.com/
> > > > > 
> > > > > All errors (new ones prefixed by >>):
> > > > > 
> > > > >     In file included from include/linux/gfp.h:7,
> > > > >                      from include/linux/mm.h:7,
> > > > >                      from arch/loongarch/kernel/asm-offsets.c:9:
> > > > > > > include/linux/mmzone.h:1749:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
> > > > >      1749 | #error Allocator MAX_ORDER exceeds SECTION_SIZE
> > > > >           |  ^~~~~
> > > > 
> > > > +Loongarch folks.
> > > LoongArch defines SECTION_SIZE_BITS as 29, so I think the upper limit
> > > of ARCH_FORCE_MAX_ORDER should not be 63, MIPS is similar.
> > The ranges MIPS add LoongArch define for ARCH_FORCE_MAX_ORDER are insane.
> > I'm going to drop them and leave ARCH_FORCE_MAX_ORDER an int with sane
> > defaults.
> > 
> > As for this splat, in the .config above ARCH_FORCE_MAX_ORDER=14 and
> > PAGE_SIZE=64k, so we end up with MAX_ORDER + PAGE_SHIFT being 30, that's
> > larger than SECTION_SIZE.
> > 
> > AFAIK randconfig does not randomize integers, so it's unclear to me how
> > ARCH_FORCE_MAX_ORDER got to 14.
> > 
> 
> As far as I can see, arch/loongarch/Kconfig has the following lines:
> 
> > config ARCH_FORCE_MAX_ORDER
> >         int "Maximum zone order"
> >         range 14 64 if PAGE_SIZE_64KB
> >         default "14" if PAGE_SIZE_64KB
> >         range 12 64 if PAGE_SIZE_16KB
> >         default "12" if PAGE_SIZE_16KB
> >         range 11 64
> >         default "11"
> 
> So the value 14 is because PAGE_SIZE_64KB is being set, which I confirmed to
> be the case with this particular run. And I believe the stanza is inherited
> from arch/mips.

With Kirill's patch the range became '13 63', so I don't see why randconfig
would set ARCH_FORCE_MAX_ORDER to 14.
 
> Looking at other arches it seems a much smaller upper limit would be
> desirable. Even the lower limit of 14 could be lowered, e.g. arch/powerpc
> has "range 8 9 if PPC64 && PPC_64K_PAGES". Is that okay?

I don't think architectures should mess with MAX_ORDER unless strictly
necessary. Having an integer config symbol with sensible defaults is enough
to ensure that MAX_ORDER can fit a PMD page.

I really doubt anyone should ever override that default in their kernel
builds.
 
> -- 
> WANG "xen0n" Xuerui
> 
> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
> 

-- 
Sincerely yours,
Mike.