linux-kernel - Re: [RFC/Requirements/Design] h/w error reporting

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, 10 Nov 2010 11:52:40 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, "Luck, Tony" <tony.luck@...el.com>,
	linux-kernel@...r.kernel.org, ying.huang@...el.com, bp@...en8.de,
	tglx@...utronix.de, akpm@...ux-foundation.org, mchehab@...hat.com,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [RFC/Requirements/Design] h/w error reporting

On Wed, 2010-11-10 at 16:30 +0100, Peter Zijlstra wrote:

> As for the buffer, I prefer a u64 aligned data stream, but the very
> least I need is frame encapsulation. What I don't want _ever_ is stupid
> sub-buffers. And no they're not needed, see the discussion about sync
> markers a while back.

BTW, the sub buffers is just an implementation detail. I suspect that
we'll have to end up with something that splits the buffer up. Whether
we have 'markers' or something else. They all break down the buffer into
a "sub-buffer".

> 
> I also don't want to support the stupid concurrent read/write from tail.

I was thinking about this more. I guess it can work if the reader always
goes the opposite direction of the writer. It's just any user that uses
this will need to cope with it. I would personally like both methods
implemented. One as the "broken design" (as you put it) which removes
the burden of sorting from the user. But the "fast design" which
requires the end result having to be able to sort the buffer.

> 
> What I do want is both mmap() and splice(), this means buffer size needs
> to be specified at buffer creation.

Sure.

> 
> I currently support overwrite (flight-recorder) and non-overwrite modes
> depending on PROT_WRITE, I guess that can easily be pushed into the
> buffer create call.

yep.

> 
> As to the mmap() part, it needs a control page to expose the head/tail
> pointers and some data.

But lets make this somehow generic, where it can be used by all sorts.

> And as you know I need to write > PAGE_SIZE entries.

Sure.

Also, lets not focus now on implementation. Let's try to concentrate on
what we want the tools to be able to do.

For example, I would like:

Very small entries, and pick and chose what I want in my entries.

A way to read it fast to a file or over the network (splice).

The read backwards seems like a cool idea, but I would not want to throw
away the read forwards part either.

How we implement this, we can work together on.

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