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 09:15:22 -0700
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	Paul Mackerras <paulus@...ba.org>
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

Paul Mackerras wrote:
> 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.

Interesting. Thanks for finding that ioctl error!  That really had me 
stumped.

Another hypothesis is that the old PAPI code would open, mmap, close, 
then reopen, and mmap again.  I wonder if because I wasn't munmap'ing 
before the close, that I got some strange behavior from the kernel. 
I'll try that today with that test case.

Thanks!

- Corey


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