linux-kernel - RE: RAS trace event proto

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]

Message-ID: <3908561D78D1C84285E8C5FCA982C28F03DA60@ORSMSX104.amr.corp.intel.com>
Date:	Wed, 22 Feb 2012 00:58:37 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Borislav Petkov <bp@...64.org>,
	Steven Rostedt <rostedt@...dmis.org>
CC:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	edac-devel <linux-edac@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: RAS trace event proto

> > > > Also, folding everything into just one string prevents (or make hard) the usage of
> > > > the perf filters, for example, to filter only the errors at the memory controller 1.
> > > 
> > > Huh, because you can't grep through the trace anymore...?
> > > 
> > 
> > I believe Mauro is talking about the tracing filters used by both perf
> > and ftrace that lets you ignore trace events when the contents of the
> > event does not match the filter. This is filtering out events before
> > they go to the buffer.
>
> Oh ok, in that case we could filter the errors - if needed - before they
> get even reported. I say "if needed" because normally we want to collect
> all hw errors in the trace, IMHO.

I'm also struggling to understand an end-user use case where you would
want filtering.  Mauro - can you expand a bit on why someone would just
want to see the errors from memory controller 1?

My mental model of the world is that large systems have some background
noise - a trickle of corrected errors that happen in normal operation.
User shouldn't care about these errors unless they breach some threshold.

When something goes wrong, you may see a storm of corrected errors, or
some uncorrected errors. In either case you'd like to get as much information
as possible to identify the component that is at fault. I'd definitely like
to see some structure to the error reporting, so that mining for data patterns
in a storm isn't hideously platform dependent.

It might be easier to evaluate the competing ideas here with some sample
output in addition to the code.

-Tony

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