linux-kernel - Re: [RFCv2 4/4] perf: util: support sysfs supported

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, 18 Jul 2016 16:00:45 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	linux-kernel@...r.kernel.org, acme@...nel.org,
	adrian.hunter@...el.com, alexander.shishkin@...ux.intel.com,
	hekuang@...wei.com, jolsa@...nel.org, kan.liang@...el.com,
	mingo@...hat.com, peterz@...radead.org, wangnan0@...wei.com
Subject: Re: [RFCv2 4/4] perf: util: support sysfs supported_cpumask file

On Mon, Jul 18, 2016 at 04:30:18PM +0200, Jiri Olsa wrote:
> On Fri, Jul 15, 2016 at 11:08:13AM +0100, Mark Rutland wrote:
> > For system PMUs, the perf tools have long expected a cpumask file under
> > sysfs, describing the single CPU which they support events being
> 
> single cpu? it's cpumask.. 

Indeed.

The issue is that in practice, due to an internal inconsistency the
perf tools only work work when a single CPU is described in the mask.
More details below (and in patch 1).

> > opened/handled on. Prior patches in this series have reworked this
> > support to support multiple CPUs in a mask, as is required to handle
> > heterogeneous CPU PMUs.
> > 
> > Unfortunately, adding a cpumask file to CPU PMUs would break existing
> > userspace. Prior to this series, perf record will refuse to open events,
> 
> I'm lost.. we already have 'cpumask' file under pmu..

Sorry, I should spell out the problem more concretely:

When manipulating events, the tools sometimes use evsel->cpus, and other
times evlist->cpus. Sometimes, the two are used inconsistently, which
only works if they are the same size and/or describe the same CPUs.
Patch 1 fixes an instance of this, where the inconsistency results in
treating uninitialised memory as perf event FDs.

In the absence of a PMU cpumask file, the evsel's cpumask is initialised
to that of the evlist, so things line up.

Currently the only PMUs which happen to expose a cpumask are uncore
PMUs, which in practice only describe a single CPU.

When recording system-wide, various parts of the perf tools assume a
single CPU, regardless of evlist->cpus, for the purpose of manipulating
events. This happens to make uncore PMUs work, avoiding the
inconsistency.

Were we to just add a 'cpumask' file to our CPU PMUs, we would break
existing userspace (e.g. hitting the issue fixed in patch 1).

The difference in naming allows new userspace to do the right thing
while not breaking existing userspace, though I agree it's somewhat
clunky.

> > and perf stat may unexpectedly block at exit time. In the absence of a
> > cpumask, perf stat is functional.
> > 
> > To address this, this patch adds support for a new file,
> > supported_cpumask, which can be used to describe heterogeneous CPUs,
> > without the risk of breaking existing userspace binaries.
> 
> is there kernel patch adding supported_cpumask support?

Modulo the naming, a patch exists [1]. We were holding off adding that
until we'd figured out how to address breaking existing userspace [2].

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438239.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/441953.html