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 16:47:17 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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, Linus Torvalds wrote:

> 
> 
> On Wed, 24 Sep 2008, Steven Rostedt wrote:
> 
> > 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.

OK, then how about this?

Each page will start with a time stamp (I'm still aligning everything by 8 
bytes, just because it simplifies things). Then we can have a 3 byte
(24 bit) counter offset? Then we can have a header that looks like:

struct {
	unsigned char time[3];
	unsigned char length;
	unsigned char buff[];
};

This still allows me to have the 2048 byte size buffer.

Or is 24 bits for time too small? The offest will be from the previous
entry, and not the beginning of the page.

If one defines a fixed size entry, we could just use the full 32 bits for 
the timestamp, since the length will be ignored in that case, and will 
become part of the buffer.

Hence,

struct {
	unsigned int time;
	unsigned char length;
	unsigend char buff[];
};



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

OK, I'll hack something up like this.

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

OK, the bottom layer will have some kind of timestamps. Now we only need 
to agree on what the header will look like.

Thanks,

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