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]
Date:   Fri, 20 Oct 2017 10:49:39 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Rakib Mullick <rakib.mullick@...il.com>
Cc:     peterz@...radead.org, mka@...omium.org, longman@...hat.com,
        adobriyan@...il.com, tglx@...utronix.de, akpm@...ux-foundation.org,
        tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.


* Rakib Mullick <rakib.mullick@...il.com> wrote:

>  cpulist_parse() uses nr_cpumask_bits as limit to parse the
> passed buffer from kernel commandline. What nr_cpumask_bits
> represents varies depends upon CONFIG_CPUMASK_OFFSTACK option.
> If CONFIG_CPUMASK_OFFSTACK=n, then nr_cpumask_bits is same as
> NR_CPUS, which might not represent the # of cpus really exist
> (default 64). So, there's a chance of gap between nr_cpu_ids
> and NR_CPUS, which ultimately lead towards invalid cpulist_parse()
> operation. For example, if isolcpus=9 is passed on a 8 cpu
> system (CONFIG_CPUMASK_OFFSTACK=n) it doesn't show the error
> that it suppose to.
> 
> This patch fixes this issue by effectively find out the last
> cpu of the passed isolcpus list and checking it with nr_cpu_ids.
> Also, fixes the error message where the nr_cpu_ids should be
> nr_cpu_ids-1, since the cpu numbering starts from 0.
> 
> Signed-off-by: Rakib Mullick <rakib.mullick@...il.com>
> ---
>  include/linux/cpumask.h | 16 ++++++++++++++++
>  kernel/sched/topology.c |  8 +++++---
>  2 files changed, 21 insertions(+), 3 deletions(-)

What kernel is this against? It does not apply to the latest kernels.

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ