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 09:49:39 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
cc:	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com, "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, Mathieu Desnoyers wrote:
> 
> I remembered other concerns about 27 vs 32 bits TSC decision, which are
> rather important. First, if we have a 27 bits TSC, with overflow every
> 33ms at 4GHz, we assume the kernel will _never_ have an interrupt
> latency longer than this for correct heartbeat behavior.

We do no such thing.

Guys, the heartbeat is a _separate_ thing from overflow handling.

You don't handle overflow by having a heartbeat that beats fifty times a 
second just to insert events, just so that the TSC delta would always fit 
in 27 bits. That would work, but be stupid. It would mean that you fill up 
your event buffer with uninteresting crud just because nothing happens.

Yes, many people want to have a heartbeat (a "Mark" event) every once in a 
while, but what I suggest is independent of heartbeats, even if it _could_ 
be implemented that way. What I suggest is simply that when you insert an 
event, you always read the full 64 bits of TSC (on x86 - others will do 
other things), and then you insert the delta against the last one.

After all, you cannot read just 27 bits of the TSC anyway. You _have_ to 
read the whole 64 bits, and then you subtract the pervious trace event TSC 
(that you have in the per-CPU trace buffer header) from that. You now have 
a delta value.

And if the delta doesn't fit in 27 bits, you generate a 59-bit TSC event!

None of this has _anything_ to do with interrupt latency. There is no 
dependency on a heartbeat, or any dependency on always inserting a trace 
event at least 30 times a second. There's no worry about conversions, and 
these are all trivial single assembly instructions to do (or a couple, on 
a 32-bit architecture that needs to do a sub/sbb pair and test two 
different registers to see if the result fits in 27 bits).

The only issue is that if you insert trace events more seldom, you'll 
always get the extra TSC event as well, inserted automatically in front of 
the event you explicitly inserted. The tracer doesn't need to know.

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