linux-kernel - Re: [PATCH 3/5] perf_counter: rework ioctl()s

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:	Tue, 12 May 2009 16:16:42 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/5] perf_counter: rework ioctl()s

Corey Ashford writes:

> I was seeing that on Power5.  On 5/6/2009, I sent along a test case that was 
> supposed to duplicate the sequence of operations, without using PAPI, to Peter 
> Zijlstra, cc'ing you.  However, I was unable to get any signals delivered to 
> user space with that code, so I was unable to reproduce the problem outside of 
> the PAPI test case.  I don't know why signal delivery doesn't work with that 
> test case... I spent quite a lot of time verifying that it was doing the right 
> thing, but could never get it to work.

I tried your test program out today, with the ioctl calls changed to
add an extra 0 argument, like this:

   ioctl(fd[0], PERF_COUNTER_IOC_ENABLE, 0);

and similarly for the disable call.  It all seemed to be fine.  There
is still a little problem with enabling counters - it doesn't happen
right away.  I have a patch to fix that, which I'll send out, and with
that patch I get:

# ./test_group_disable 
evt[0].config = 0
evt[1].config = 4
group_leader = -1
evt[i].wakeup_events = 0
successfully opened evt[0].  fd[0] = 3
group_leader = 3
evt[i].wakeup_events = 0
successfully opened evt[1].  fd[1] = 4
successfully attached signal handler
fd 3's mmap buffer is located at 0xfffab4b3000
successfully tuned up fd 3
fd 4's mmap buffer is located at 0xfffab4aa000
successfully tuned up fd 4
enable was successful
CYCLES: 20904
BRANCHES: 2413
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 4
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 4
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 4
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
signal received while counters are enabled. fd = 3
disable was successful
CYCLES: 180149676
BRANCHES: 30030826
CYCLES: 180149676
BRANCHES: 30030826
CYCLES data_head: 141b0
BRANCHES data_head: 35a0
#

So clearly it is getting signals when the leader is enabled, one per
page of events, and not when the leader is disabled.  I notice you
have evt[].wakeup_events set to 0, which is presumably why we don't
get more signals than we do.

Paul.
--
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/