linux-kernel - Re: [PATCH] sched/isolcpus: Show isolated cpu map

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: <a4700cec-fa6b-d9f2-d4bf-312525be2c6f@huawei.com>
Date:   Tue, 14 Feb 2017 09:53:52 +0800
From:   Kefeng Wang <wangkefeng.wang@...wei.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Ingo Molnar <mingo@...nel.org>, <linux-kernel@...r.kernel.org>,
        <guohanjun@...wei.com>, Prarit Bhargava <prarit@...hat.com>,
        Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] sched/isolcpus: Show isolated cpu map



On 2017/2/13 21:32, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 09:07:02PM +0800, Kefeng Wang wrote:
>> Hi Peter
>>
>> +Tejun
>>
>> On 2017/2/13 20:06, Peter Zijlstra wrote:
>>> On Mon, Feb 13, 2017 at 05:43:59PM +0800, Kefeng Wang wrote:
>>>> The commit a6e4491c682a ("sched/isolcpus: Output warning when the
>>>> 'isolcpus=' kernel parameter is invalid") adds an error message
>>>> when specified cpu bigger than nr_cpu_ids, but nr_cpumask_bits in
>>>> cpulist_parse() could be nr_cpu_ids or NR_CPUS.
>>>>
>>>> eg, NR_CPUS=64, nr_cpu_ids=8 in ARM64, cpulist_parse() won't return
>>>> -ERANGE if isolcpus=1-10;
>>>>
>>>

> OK, so its wrong both ways.
> 
> Problem seems to be that cpumask is internally inconsistent with the
> number of bits because a small constant NR_CPUS is more efficient for
> things like cpumask_subset().
> 
> If everything were consistent and used nr_cpu_ids it would all be fine,
> but using a mixture is giving pain.
> 
> Does something like the below work? It parses up to nr_cpu_ids and then
> and's with cpu_possible_mask (which has all bits set). In case
> nr_cpumask_bits is larger than nr_cpu_ids this should result in clearing
> the top bits (and therefore not leave them uninitialized). And using
> nr_cpu_ids for parsing now makes the range check work again.

It works again for the above example, but there is another scene,
eg, NR_CPUS=64, nr_cpu_ids=8 and isolcpus=1,2,3,4,5,6,7,8,9,10 on arm64

It prints the error message, but it does isolate cpus successfully.

if isolcpus=1-10, it will only show error message and fail to isolate cpus.

For our user, they may use the two kinds of configuration, but they make some
mistake sometimes and fail to isolated cpus. That's primary reason why I want
to show the isolated cpus map on boot message.

> 
> 
> 
> .
>