linux-kernel - Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

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:   Mon, 6 Feb 2017 11:20:27 -0500
From:   Tejun Heo <tj@...nel.org>
To:     Martin Steigerwald <martin.steigerwald@...mix.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>, Andrew Morton <akpm@...l.org>,
        Ingo Molnar <mingo@...e.hu>,
        LKML <linux-kernel@...r.kernel.org>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Jay Lan <jlan@...r.sgi.com>,
        Martin Steigerwald <martin@...htvoll.de>,
        Gerlof Langeveld <gerlof.langeveld@...ptool.nl>,
        Marc Haber <mh+debian-packages@...schlus.de>,
        Ben Hutchings <ben@...adent.org.uk>,
        Balbir Singh <bsingharora@...il.com>
Subject: Re: [REGRESSION] Two issues that prevent process accounting
 (taskstats) from working correctly

Hello,

On Mon, Feb 06, 2017 at 11:39:04AM +0100, Martin Steigerwald wrote:
> > Ben Hutchings reports:
> > 
> > "It looks like the taskstats bug was introduced by 513e3d2d11c9 as that
> > means cpumask_parse() may not initialise as many bits as
> > cpumask_subset() compares"

I see, so that patch switched parsing and printing to always use
nr_cpu_ids but left the comparison functions to keep using
nr_cpumask_bits which may be NR_CPUS instead of nr_cpu_ids.

> Okay, any conclusion out of this? Any feedback from the maintainers of this 
> code?

We can switch back the parse functions to nr_cpumask_bits, or just get
rid of nr_cpumask_bits and use nr_cpu_ids everywhere.  The only reason
we use nr_cpumask_bits is because on small configurations the constant
NR_CPUS can be more efficient than having to read out nr_cpu_ids
variable each time.

Hmm... I'll restore the parse functions to use nr_cpumask_bits instead
for now.  The confusing part was the output results.  Input should be
okay even if we flip between nr_cpu_ids and NR_CPUS.

Thanks.

-- 
tejun