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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8734rhyl1g.ffs@tglx>
Date: Fri, 19 Apr 2024 07:32:43 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Alexey Dobriyan <adobriyan@...il.com>, peterz@...radead.org
Cc: adobriyan@...il.com, yury.norov@...il.com, linux@...musvillemoes.dk,
 akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpu: memoise number of possible cpus

On Thu, Apr 18 2024 at 07:19, Alexey Dobriyan wrote:

memoise?

> cpu_possible_mask is fixed after boot, so it makes sense
> to calculate number of possible cpus to

The kernel calculates the number of possible CPUs already today, no?

> a) make num_possible_cpus() faster (distros ship with _large_ NR_CPUS),
> b) unscrew codegen elsewhere replacing function call
>    with simple memory load.

Can we please have complete sentences which use precise technical
wording to describe the changes?

> diff --git a/init/main.c b/init/main.c
> index 881f6230ee59..fe0291b44d78 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -904,6 +904,9 @@ void start_kernel(void)
>  	setup_boot_config();
>  	setup_command_line(command_line);
>  	setup_nr_cpu_ids();
> +#if NR_CPUS > 1
> +	num_possible_cpus = cpumask_weight(cpu_possible_mask);
> +#endif

setup_nr_cpu_ids() does exactly the same thing despite using a different
algorithm. So why not do the obvious and have:

#define num_possible_cpus()	nr_cpu_ids

and make nr_cpu_ids __ro_after_init?

Which made me look at CONFIG_FORCE_NR_CPUS. That's simply broken
because:

static inline void set_nr_cpu_ids(unsigned int nr)
{
#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
       WARN_ON(nr != nr_cpu_ids);
#else
        nr_cpu_ids = nr;
#endif
}

So if num_possible_cpus() != nr_cpu_ids then everything after that
becomes lottery. If that hard-coded NR_CPUS is actually worth it then
this WARN_ON() is just wrong. The only sensible solution to that is to
make it a BUG_ON().

Thanks,

        tglx


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ