linux-kernel - Re: Hardware Error Kernel Mini-Summit

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:	Mon, 14 Jun 2010 12:03:20 +0200
From:	Nils Carlson <nils.carlson@...d.ltu.se>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Borislav Petkov <bp@...64.org>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	"Luck, Tony" <tony.luck@...el.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	"Young, Brent" <brent.young@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"bluesmoke-devel@...ts.sourceforge.net" 
	<bluesmoke-devel@...ts.sourceforge.net>,
	Andi Kleen <andi@...stfloor.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Doug Thompson <dougthompson@...ssion.com>,
	Joe Perches <joe@...ches.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: Hardware Error Kernel Mini-Summit


On May 19, 2010, at 9:09 AM, Ingo Molnar wrote:
>
> Basically the idea behind the generic structured logging
> framework (the perf events kernel subsystem) is to have
> both ASCII output (where desired: critical errors), but to
> also have well-specified event format parsable to
> user-space tools.
>
> Plus there's the need for fast, lightweight, flexible
> event passing mechanism - which is given by the perf
> events transport which enables arbitrary size in-memory
> ring-buffers, poll() and epoll support, etc.
>
> perf events supports all these different usecases and
> comes with a (constantly growing) set of events already
> defined upstream. We've got more than a dozen different
> upstream subsystems that have defined events and we have
> over a hundred individual events. There's a rapidly
> growing tool space that makes case by case use of these
> event sources to measure/observe various aspects of the
> system.
>
> Regarding dmesg, there's a WIP patch on lkml that
> integrates printks into this framework as well - makes
> each printk also available as a special string event.
>
> That way a tool can have both programmatic access to
> printk output (without having to interact with the syslog
> buffer itself) - together with all the other structured
> log sources, while humans can also see what is happening.

Just left the above for reference. How would this affect other
aspects of EDAC such as the error injection, the sysfs
entries that (in most cases) reflect the layout of dimm's, and
allow the setting of scrub rate? If we're just talking about
replacing all instances of printk (when logging single bit
errors) with perf events, I don't really see that as a problem.
But EDAC is much more than that today...

Thoughts, comments?

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