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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Sep 2008 13:23:47 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
cc:	Martin Bligh <mbligh@...gle.com>,
	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

On Wed, 24 Sep 2008, Steven Rostedt wrote:
> 
> Right now I have a list of pages that make up the ring buffer. Are you 
> saying that the first entry in the page should be a timestamp?

I think the most straightforward model would be that the "head" of the 
ring buffer (regardless of size in pages) would have that timestamp. 
Making them per-page is an option, of course, I have no strong opinions 
either way. The per-page one could have advantages (ie it would give a 
nice upper limit for just how many entries you have to walk in order to 
convert an entry into a full timestamp), but I certainly don't think 
that's a big decision, more of a detail.

But if we start out with having the full TSC in each entry, that's easily 
going to be painful to fix later. If we start out with a delta system, 
changing the details of where the base is gotten is likely to be exactly 
that - just a detail.

So I'd like the thing to have small headers, and be designed from the 
start to have small headers.

> I will now have a ring_buffer API, which will do basic recording. It will 
> have two modes when allocated. Fixed sized entry mode where you can just 
> put whatever you want in (I'm still aligning everything by 8 bytes, just 
> since memory is cheap). Or you can have variable length mode that will 
> make the following event header:
> 
> struct {
> 	unsigned char length;
> 	unsigned char buff[];
> };

So the only reason I'm not thrilled with this is that I really think that 
timestamping should be inherent, and at the lowest level.

Without timestamping, what's the real point? EVERYBODY eventually wants a 
timestamp. We added it even to the kernel printk()'s. People want them for 
network packets to user space. X wants it for all its events. It's one of 
those things that people never do from the beginning, but that everybody 
eventually wants anyway.

So I certainly don't mind layering, but I *do* mind it if it then means 
that some people will use a broken model and not have timestamps. So I 
think the timestamping code should just be there - without it, a trace 
buffer is pointless.

		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/