linux-kernel - Re: [lib/cpumask] 6f9c07be9d: WARNING:at_include/linux/cpumask.h:#prefill_possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y1JvofRR2APc4HK8@yujie-X299>
Date:   Fri, 21 Oct 2022 18:08:33 +0800
From:   Yujie Liu <yujie.liu@...el.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Yury Norov <yury.norov@...il.com>, <lkp@...ts.01.org>,
        <lkp@...el.com>, <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [lib/cpumask] 6f9c07be9d:
 WARNING:at_include/linux/cpumask.h:#prefill_possible_map

Hi Geert,

On Fri, Oct 21, 2022 at 08:39:10AM +0200, Geert Uytterhoeven wrote:
> Hi Yukie,
> 
> On Thu, Oct 20, 2022 at 7:40 PM Yujie Liu <yujie.liu@...el.com> wrote:
> > On Thu, Oct 20, 2022 at 09:11:21AM -0700, Yury Norov wrote:
> > > On Thu, Oct 20, 2022 at 06:05:51PM +0800, kernel test robot wrote:
> > > > We noticed that below patch adds a FORCE_NR_CPUS config, and it is
> > > > expected to show a warning when this config is enabled and
> > > > CONFIG_NR_CPUS doesn't match the actual number of CPUs we have. But we
> > > > also noticed that it not only shows a warning but could also break boot
> > > > test in some cases. We are not sure if the break is actually related to
> > > > this patch or not, so we send this report FYI.
> > > >
> > > > We noticed that a fix patch was posted at:
> > > >
> > > > https://lore.kernel.org/all/20221019225939.1646349-1-yury.norov@gmail.com/
> > > >
> > > > FORCE_NR_CPUS won't be enabled by allmodconfig or allyesconfig after
> > > > applying the fix, but looks it could still be enabled by randconfig. Not
> > > > sure if this is an expected behavior, but since our test robot runs many
> > > > randconfig tests, this warning could still be triggered frequently and
> > > > go to boot failure at last.
> > > >
> > > > Please kindly help to give some advice on handling this config in our
> > > > testing. Thanks.
> > > >
> > > > Please check below report for more details:
> 
> > > Indeed, if FORCE_NR_CPUS is enabled by randconfig, it may cause at least
> > > boot warning. I'm either not sure if the following alloc_pages is
> > > related to the config, but anyways...
> > >
> > > The most logical solution would be disabling FORCE_NR_CPUS in
> > > randconfig before building the kernel. We can do it in a post-script,
> > > like:
> > >
> > > make randconfig
> > > scripts/config -d FORCE_NR_CPUS
> > > scripts/config -e UNFORCE_NR_CPUS
> > > make
> >
> > This seems to need extra work to run config script for each randconfig
> > build.
> 
> While randconfig is great for doing build tests, I would not use it
> for boot tests, until you have some way to make sure critical options
> are enabled (or disabled).  A plain randconfig kernel is almost
> guaranteed to lack some driver you need.

Thanks for the comment. I just realized that we do have this process in
our test robot. It will fixup randconfigs to make sure critical configs
are properly set to fit our boot test environment. I should also disable
FORCE_NR_CPUS in this process and this issue is easily resolved.

> > > Or we can create a pre-configuration file, so that randconfig would do
> > > its work based on that. We already have such pre-configs for powerpc
> > > and risc:
> > >         arch/riscv/configs/32-bit.config
> > >         arch/powerpc/configs/32-bit.config
> > >         arch/powerpc/configs/64-bit.config
> > >         arch/riscv/configs/64-bit.config
> > >
> > > Maybe it's time to create a generic config of this sort.
> >
> > It would be nice to have a pre-config file to ensure this config won't
> > be enabled accidentally by randconfig if users are not aware of. This
> > would also be consistent with common build flow so no extra steps are
> > needed.
> 
> The above configs don't contain any options controlling included
> drivers.
> Which options would you add to it? This is very platform-specific.

By disabling FORCE_NR_CPUS in randconfig fixup, seems we don't need to
have above config constraints. My apologies for raising this naive
problem, we should have addressed this issue internally before seeking
help from developers. Sorry for bothering.

> > > Please let me know if that sounds sane to you. I'm not very familiar
> > > to build system things, but I'll be happy to help implementing this,
> > > if needed.

--
Best Regards,
Yujie