linux-kernel - Re: perf: regression with PERF_EVENT_IOC

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, 24 May 2011 11:04:43 -0400 (EDT)
From:	Vince Weaver <vweaver1@...s.utk.edu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	linux-kernel@...r.kernel.org, fbuihuu@...il.com, mingo@...e.hu,
	paulus@...ba.org, acme@...hat.com
Subject: Re: perf: regression with PERF_EVENT_IOC_REFRESH

On Tue, 24 May 2011, Peter Zijlstra wrote:

> > The old behavior might have been unintentional, but PAPI unfortunately 
> > depends on it (not code I originaly wrote, but code I have to maintain).
> 
> Right, so what the code does is create a group of which the leader is
> disabled, which effectively has the whole group disabled. It then abuses
> REFRESH,0 to enable the leader.

yes.  This is currently what PAPI does.

> The code should use ENABLE (surprise, surprise!) to enable the leader
> and get things going.

It was unclear from the documentation that enabling a group leader that 
had siblings with overflow setup would start them triggering
without some sort of REFRESH first.  It does seem to work though.
But then again, so did the original behavior.

> This is very clear abuse of the API and I'm not really inclined to fix
> it, in fact, I'd be tempted to add an additional test to verify the
> argument to REFRESH > 0.

Well, when there's no documentation then people write to the code.
As I said before, I didn't write this code.  I just get to pick up the 
pieces when it breaks.

As an aside, I also wasted 6 hours last night finding out that you don't 
get signaled on overflow if you don't have a ring-buffer mmap()ed, even
if you never read from the buffer and you only are interested in counting
the number of overflows.  I should stop complaining though or you'll
start telling me to fix the documentation.  Which maybe I would do if I 
didn't spend all my time writing code to reproduce problems in the perf 
ABI for bisection purposes.

> Then again, I do appreciate you're having a problem there, how soon can
> you push this trivial fix into all maintained PAPI branches? We could
> revert this for one release and then properly shut this abuse down the
> next release.

well since you apparently aren't going to retroactively revert it for 
2.6.37, 2.6.38, or 2.6.39 then it would be silly to do it just for 2.6.40.

I'll audit the PAPI code to see how widespread it is.

To warn you though, we still have people complain within hours when we 
break support for 2.6.16 kernels, so it's not like the people who use 
PAPI are the kind to run out and install a minor stable release.  They're
going to upgrade their distro or move their binary to a newer machine and 
suddenly start geting EINVAL returns on their previously working code and 
then start noisily complaining.

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/