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:	Wed, 24 Sep 2008 09:56:20 -0700
From:	"Martin Bligh" <mbligh@...gle.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Peter Zijlstra" <peterz@...radead.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,
	"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

>> Most people will want the events to be as _small_ as humanly possible. The
>> normal event size should hopefully be in the 8-16 bytes, and I think the
>> RFC patch is already broken because it allocates that insane 64-bit event
>> counter for things. Who the hell wants a 64-bit event counter that much?
>> That's broken.
>
> The event counter is just the timestamp (quick patch, simple to fix). The
> term "counter" was bad. It should have been timestamp, which one would
> want a 64bit timestamp. Or at least a way to figure it out. Yes, we can
> store a special event called "timestamp" and have a smaller counter. But
> for simplicity, the 64 bit was easy. The event id was just 16 bits, which
> I think is way more than enough.

Yup, is just a confusing name. we can definitely make this a smaller field
by doing an offset time from the last event, but we agreed on 64 bits to
keep version 1 simple ;-)

I think in retrospect the timestamp events we used with wall time stuck
in them were a mistake, as NTP will make them difficult. We should have
just recorded wall time at the start of the buffer, and done offsets from
there.

Without relayfs subbuffers, the offset thing gets trickier, as you'd have
to update the "start time" constantly once you'd filled the buffer and
were shifting the start pointer. OTOH, I guess it's only 1 cacheline.

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