linux-kernel - Re: [PATCH] Fix isocpus's param handling when CPUMASK

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: <20171020084939.r6ox4o7k2kgezzbk@gmail.com>
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