linux-kernel - Re: [tip:perfcounters/core] perf_counter: record time running and time enabled for each counter

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:	Thu, 26 Mar 2009 10:23:10 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org,
	tglx@...utronix.de, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/core] perf_counter: record time running and
 time enabled for each counter

Corey Ashford writes:

> This change looks good to me, except:
> 
> How do I know which value comes first after the counter value if I have 
> both PERF_FORMAT_TOTAL_TIME_ENABLED and PERF_FORMAT_TOTAL_TIME_RUNNING 
> set?  Are they in the order of their enum values?

Yes.

>  The order should be 
> described somewhere.

This comment that I added to perf_counter.h:

/*
 * Bits that can be set in hw_event.read_format to request that
 * reads on the counter should return the indicated quantities,
 * in increasing order of bit value, after the counter value.
 */

describes the order ("in increasing order of bit value").  So you will
get the count, total time enabled, total time running, in that order.

>  Is there anything to keep a kernel code change 
> from inadvertantly reversing the position of two values at some point in 
> the future?

Well, that would be an ABI breakage.  Once it's upstream, we won't
break the ABI, and if someone does break it and no-one realizes at the
time, we'll revert their change once we do realize.  (With a possible
exception for security holes that can't be fixed without breaking the
ABI, of course, but I can't see how that would be the case here.)

Until it goes into Linus' tree, we can still change the ABI in
incompatible ways.  Ingo and Peter are talking about using a tagged
format for the data obtained from read(), which would solve your
problem in another way, though it would make the userspace code more
complicated (it would have to check that the tags were what it was
expecting, and cope with the situation where it doesn't get a value it
needs).

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/