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]

Message-ID: <4A086A89.6030905@linux.vnet.ibm.com>
Date:	Mon, 11 May 2009 11:12:25 -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:
> Peter Zijlstra writes:
> 
>> Corey noticed that ioctl()s on grouped counters didn't work on the whole group.
>> This extends the ioctl() interface to take a second argument that is
>> interpreted as a flags field. We then provide PERF_IOC_FLAG_GROUP to toggle
>> the behaviour.
>>
>> Having this flag gives the greatest flexibility, allowing you to individually
>> enable/disable/reset counters in a group, or all together.
> 
> As far as enable/disable are concerned, I don't think this is really
> necessary.  My intention was that if you want to enable/disable a
> whole group you just enable/disable the leader and leave all its
> siblings enabled, since if the leader is disabled the whole group
> can't go on.
> 
> Corey's problem was that we have a bug where enabling the leader only
> puts the leader on and not the enabled group members.  I meant to send
> a patch to fix that ages ago but I got distracted.  I'll send out the
> patch shortly.
> 
> Paul.

One problem that I was seeing was that disabling only the group leader didn't 
keep the group member hardware counters from continuing to run and generate 
overflows, and causing sample records to be put in the mmap buffer.

Was this the intention?

For PAPI, we really need to be able to disable, at least, the sample records 
from going into the mmap buffers.  Even better would be to stop the hardware 
counters from counting while disabled.

Otherwise, the only way I have of stopping samples from getting into the buffer 
is to munmap the buffer.


- Corey

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

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