linux-kernel - [BUG] perf_events: PERF_FORMAT_GROUP not working correctly when monitoring another task

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-next>] [day] [month] [year] [list]

Message-ID: <4BDF8118.3090200@linux.vnet.ibm.com>
Date:	Mon, 03 May 2010 19:06:16 -0700
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul Mackerras <paulus@...ba.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
CC:	Carl Love <carll@...ibm.com>, Maynard Johnson <mpjohn@...ibm.com>
Subject: [BUG] perf_events: PERF_FORMAT_GROUP not working correctly when monitoring
 another task

In the last couple of days, I've run across what appears to be a kernel bug in 2.6.33.3 (haven't tested later kernels yet) having to do with using the PERF_FORMAT_GROUP feature in combination with enable_on_exec and reading counts from a remote task.

What happens is that when we go to read the entire group up, only the first counter in can be accessed; the read() call returns too few bytes.  This problem doesn't occur if measuring the from the same task.

I have attached a "cut down", though it's not terribly small.  It is a cut down from the "task" example program in libpfm4/perf_examples.  In addition to trimming the program down a lot, I've removed the dependency on libpfm4 and made modifications so that it will compile in the tools/perf subdirectory.  If you copy the attachment into your tools/perf subdir, you should be able to compile it with just:

gcc -o show_fg_bug show_fg_bug.c

Then invoke it by passing it an executable that will give it something to chew on a little, e.g.:

./show_fg_bug md5sum `which gdb`

The test cases creates two counters and places them in the same group, and sets the PERF_FORMAT_GROUP option on the first counter.  It fork/execs the child and when the child is done executing, it reads back the counter values.

When I run it, I see this output:

% ./show_fg_bug md5sum `which gdb`
825b15d7279ef21d6c9d018d775758ae  /usr/bin/gdb
Error! tried to read 40 bytes, but got 32
            58684138 PERF_COUNT_HW_CPU_CYCLES (35469840 : 35469840)
                   0 PERF_COUNT_HW_INSTRUCTIONS (35469840 : 35469840)

Oddly enough, if you look at the "nr" (number of counters) value that gets read up as part of the group, it is two, but it can only read the first of the two counters.  Another data point is that it doesn't matter how many counters you add to the group, only the first can be read up.

Please let me know if you have any questions about this.

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR 
cjashfor@...ibm.com

View attachment "show_fg_bug.c" of type "text/plain" (6031 bytes)