linux-kernel - Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

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, 02 Apr 2013 09:19:14 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	David Ahern <dsahern@...il.com>, Pawel Moll <pawel.moll@....com>,
	Stephane Eranian <eranian@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>, Paul Mackerras <paulus@...ba.org>,
	Anton Blanchard <anton@...ba.org>,
	Will Deacon <Will.Deacon@....com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Pekka Enberg <penberg@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Robert Richter <robert.richter@....com>
Subject: Re: [RFC] perf: need to expose sched_clock to correlate user samples
 with kernel samples

On 04/02/2013 12:54 AM, Peter Zijlstra wrote:
> On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
>> I'm still not sold on the CLOCK_PERF posix clock. The semantics are
>> still too hand-wavy and implementation specific.
> How about we define the semantics as: match whatever comes out of perf
> (and preferably ftrace by default) stuff?

That's not a sane interface. We've already been bitten by semantic 
changes in sched_clock affecting in-kernel users. How are we going to 
handle this with userland in the future? What happens when applications 
depend on "what comes out of perf" on one system and that ends up being 
different on another? "Oh, its just broken, the application shouldn't be 
using that."

I'm sort of amazed that folks are so careful and hesitant to add an 
ioctl to inject a timestamp fence into perf, but then so cavalier about 
adding a ill-defined clockid as a generic interface.

> Since that stuff is already exposed to userspace, doesn't it make sense
> to have a user accessible time source that generates the same time-line
> so that people can create logs that can be properly interleaved?

Its exposed to userspace as timestamps correlated with specific data, 
not timestamps for any purpose. We export kernel function addresses via 
WARN_ON messages to dmesg, it doesn't mean we might as well allow 
userland to jump and execute those addresses. ;)

I still think exposing the perf clock to userland is a bad idea, and 
would much rather the kernel provide timestamp data in the logs 
themselves to make the logs useful. But if we're going to have to do 
this via a clockid, I'm going to want it to be done via a dynamic posix 
clockid, so its clear its tightly tied with perf and not considered a 
generic interface (and I can clearly point folks having problems to the 
perf maintainers ;).

thanks
-john

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