linux-kernel - Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output format

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 Oct 2013 10:12:35 -0700
From:	Tony Luck <tony.luck@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Chen Gong <gong.chen@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Lance Ortiz <lance.ortiz@...com>,
	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output format

On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
>> Because most of data in CPER are empty or unimportant.
>
> It is not about whether it is important or not - the question is whether
> changing existing functionality which someone might rely upon is a
> problem here? Someone might be expecting exactly those messages to
> appear in dmesg.

Pulling in a couple more people who have been touching error reporting
code in the last year or so (Hi Lance, Naveen ... feel free to drag more
people to look at this thread).

I prodded Chen Gong in to make this change because our console messages
are way to verbose (and scary) for simple corrected errors.  There are 18
fields in the memory error section (as of UEFI 2.4 ... more are likely to be
added because there are issues that some of the 16-bit wide fields are too
small to handle increased internal values in modern DIMMs).  Whether you
print that one item per line, or a few very long lines - it is way
more information
than the average user will ever want or need to see.

> Btw, what is the real reason for this patch, to save yourself the output
> in dmesg? If so, you can disable this output when eMCA module has been
> loaded but leave it intact otherwise.

This is an excellent idea - if the full data is being logged via TRACE, then
we can drop to virtually nothing on the console (just have something similar
to the "Machine check events logged" message so that people will get a
tip that they might want to go dig into other logs).  Maybe something like:
    %d corrected memory errors\n", count
[rate limited]

But we'd have to make sure that the existing user(s) of this code also
have a TRACE path.

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