linux-kernel - Re: [RFC PATCH 1/3] Unified trace buffer

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, 25 Sep 2008 18:59:59 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Tom Zanussi <zanussi@...cast.net>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer

On Thu, 25 Sep 2008, Jeremy Fitzhardinge wrote:

> Linus Torvalds wrote:
> > The reason I say "and no" is that it's not technically really possible to 
> > atomically give the exact TSC at which the frequency change took place. We 
> > just don't have the information, and I doubt we will ever have it.
> >   
> 
> Well, you don't need the tsc at the precise moment of the frequency
> change.  You just need to emit the current tsc+frequency+wallclock time
> before you emit any more delta records after the frequency change.  You
> can't fetch all those values instantaneously, but you can get close.

Even in my last version I added a "TIME_STAMP" type that can be used in 
the future to add some kind of synchronization into the trace, that reads
GTOD or whatnot.

But as you can see, I've been trying to implement these various ideas, 
since the devil is in the details and the code is the details.

How do you get this GTOD read in the ring buffer? If the ring buffer does
it without any knowledge from the tracer, it may be doing it a 
inappropriate times. This would also imply that the GTOD infrastructure 
itself is reentrent safe.  Imagine tracing the GTOD code when the buffer 
decides it is about time to add the GTOD timestamp into the buffer. Can 
the GTOD handle this recursion. If the GTOD has spinlocks, probably not.

Perhaps we can add a ring_buffer_write_safe() method that would prevent 
the trace from doing these. Or we can add a way for the tracer to trigger 
a time event (ring_buffer_tick());

> asm/x86/kernel/pvclock.c does the tsc to ns conversion with just adds
> and multiplies, but unfortunately it can't be expressed in C because it
> uses the extra precision the x86 gives for multiplies.

If we do end up making a new clock API, I imagine that each arch will 
define their own.

-- Steve

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