linux-kernel - Re: [PATCH v2 2/4] x86/mce, EDAC/mce_amd: Add support for new MCA

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: <20240710093828.GDZo5WlPrXLg-SbBHd@fat_crate.local>
Date: Wed, 10 Jul 2024 11:38:28 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Naik, Avadhut" <avadnaik@....com>
Cc: x86@...nel.org, linux-edac@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, tony.luck@...el.com,
	rafael@...nel.org, tglx@...utronix.de, mingo@...hat.com,
	rostedt@...dmis.org, lenb@...nel.org, mchehab@...nel.org,
	james.morse@....com, airlied@...il.com, yazen.ghannam@....com,
	john.allen@....com, Avadhut Naik <avadhut.naik@....com>
Subject: Re: [PATCH v2 2/4] x86/mce, EDAC/mce_amd: Add support for new
 MCA_SYND{1,2} registers

On Tue, Jul 09, 2024 at 01:27:25AM -0500, Naik, Avadhut wrote:
> IIUC, its an abbreviation of a Latin word and is used as a synonym for "namely"
> or "that is to say".
> Might not be the best choice in this case. Will change it.

I learn new stuff every day:

https://en.wikipedia.org/wiki/Viz.

> Userspace error decoding tools like the rasdaemon gather related hardware error
> information through the tracepoints. As such, its important to have these two
> registers in the tracepoint so that the tools like rasdaemon can parse them
> and output the supplemental error information like FRU Text contained in them.

Put *that* in the commit message - do not explain what the patch does.

> Got it. The first SoB entry is of the primary author. The successive SoB's are
> from the people handling and transporting the patch.

Exactly!

> IOW, the route taken by a patch, as its propagated, to maintainers and eventually
> to Linus, should be evident from the SoB chain.

You got it.

> With this set, the first two elements of the vendor data dynamic array are SYND 1/2
> registers while the third element is MCA_CONFIG (added through patch 4 of the set).
> Now, in rasdaemon, SYND1/2 register contents (i.e. first two fields) are interpreted
> as FRU Text only if BIT(9) of MCA_CONFIG (third field) is set.
> 
> Thus, we depend on array's layout for accurate FRU Text decoding in the rasdaemon.

So it sounds to me like we want to document and thus freeze the
vendor-specific blob layout because tools are going to be using and parsing
it. And this will spare us the kernel version checks.

And new additions to that AMD-specific blob will come at the end and will
have to be documented too.

That sounds like an ok compromise to me...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette