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] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1GHthWAyAq2Q+Yz@yujie-X299>
Date:   Fri, 21 Oct 2022 01:39:02 +0800
From:   Yujie Liu <yujie.liu@...el.com>
To:     Yury Norov <yury.norov@...il.com>
CC:     <lkp@...ts.01.org>, <lkp@...el.com>,
        <linux-kernel@...r.kernel.org>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        <feng.tang@...el.com>, <ying.huang@...el.com>
Subject: Re: [lib/cpumask] 6f9c07be9d:
 WARNING:at_include/linux/cpumask.h:#prefill_possible_map

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:
> > 
> > Hi Yury,
> > 
> > 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:
> > 
> > 
> > Greeting,
> 
> Hi guys,
> 
> Thanks for the report.
> 
> 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.

> 
> 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.

Best Regards,
Yujie

> 
> 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.
> 
> Thanks,
> Yury
>  

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ