linux-kernel - Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

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: <alpine.DEB.2.10.1310281002020.24060@vincent-weaver-1.um.maine.edu>
Date:	Mon, 28 Oct 2013 10:07:48 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Will Deacon <will.deacon@....com>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

On Mon, 28 Oct 2013, Will Deacon wrote:

> This was in response to complaints from both internal users and people on
> public lists:
> 
>   http://www.mail-archive.com/perfmon2-devel@lists.sourceforge.net/msg02657.html
> 
> I believe the scenario was something like:
> 
>  (1) An instruction counter is set up to overflow after 200 instructions,
>      with a SIGIO handler to print some information. It is initially
>      disabled.
> 
>  (2) At some point, the counter is enabled for 1 overflow (IOC_REFRESH)
> 
>  (3) The counter eventually overflows and the SIGIO handler is triggered.
>      At this pointer the counter is disabled.
> 
>  (4) The signal handler changes the period to 200k instructions using
>      IOC_PERIOD and enables the counter for a further overflow.
> 
>  (5) SIGIO is taken after 200 instructions, rather than 200k.

It would be nice if changelogs for patches had this level of detail.

It's also a shame this change apprently didn't hit the linux-kernel list 
as far as I can tell.  I do my best to try to note all of the perf 
ABI-related changes there, but if things like this are going to start 
getting merged in architecture trees then things get that much harder 
to keep track of.

> I don't want to be the `oddball' architecture (at least, not more than I am
> already :), but I do find it tricky to follow the required semantics of perf
> as opposed to `it happens to work this way', especially when so much of it
> is buried in the various arch backends. So if somebody using the thing on
> ARM has (what looks to me like) a valid issue, then I usually try and fix
> it.

But it was global behavior that was common on all architectures.

Now any cross-platform tool like PAPI is going to have to have a mess of 
#ifdefs around every use of this ioctl, and it will only get worse if 
other architectures decide to "fix" the problem too.

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