linux-kernel - [BUG] perf_events: PERF_FORMAT

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 9 Apr 2010 12:22:59 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
	davem@...emloft.net, robert.richter@....com,
	perfmon2-devel@...ts.sf.net, eranian@...il.com,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: [BUG] perf_events: PERF_FORMAT_GROUP fails

Hi,

I have been running some tests where I count and I am
using PERF_FORMAT_GROUP. I want to extract all counts
in one read().

It turns out that this does not work as expected. I would expect
that if I create an event group, I can ALWAYS read it with a single
read(). Turns out, it depends on the state of the events.

If the events are still attached to a task then the read() returns
the expected data  which is:

/*
 *      { u64           nr;
 *        { u64         time_enabled; } && PERF_FORMAT_ENABLED
 *        { u64         time_running; } && PERF_FORMAT_RUNNING
 *        { u64         value;
 *          { u64       id;           } && PERF_FORMAT_ID
 *        }             cntr[nr];
 */

But if you read once the monitored task has died, i.e., events are detached,
then all you get is the data for the leader of the group yet the value
of nr still
shows all the members of the group.

Here is an example with 2 events + ENABLED+RUNNING:
  - task active, events attached: read()=40 (5* 8,
5=nr+enabled+running+2*value), nr=2
  - task died, event detached: read()=32 (4*8 =
nr+enabled+running+value) yet nr=2

Seems to me the events need to be linked in sibling_list regardless of the state
they are in. And there is mismatch in how nr_siblings and sibling_list
are managed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/