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 13:05:29 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"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 18:48 +0100, Ingo Molnar wrote:

> Yep. The obvious direction is to extend the event buffering ABI we already have, 
> with whatever additions that are needed:
> 
>  - document that we already support flight recorder mode

I thought this was still broken?

> 
>  - a more compressed record format
> 
>  - NOP filler events up to page boundary, for better splice and for better flight 
>    recorder
> 
>  - splice support
> 
> etc. That's how it evolved until now and it's all very extensible.
> 
> Steve, could you please list the additions you have in mind, in order of priority?

A few of things that pop up quickly are:

1) lockless

2) as-fast-as possible

3) support all tasks / all CPUs and still have as-fast-as-possible

Peter said at LPC that the perf buffering system was not designed to
handle high speed tracing. But he also said he does not like the way the
ftrace buffering works.

I think if we take a step back, we can come up with a new buffering/ABI
system that can satisfy everyone. We will still support the current
method now, but I really don't think it is designed with everything we
had in mind. I do not envision that we can "envolve" to where we want to
be. We may have to bite the bullet, just like iptables did when they saw
the failures of ipchains, and redesign something new now that we
understand what the requirements are.

I do think we need to come up with something new but still support the
old methods. Thomas came up with this idea, and Peter, Frederic and
myself agreed.

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