linux-kernel - Re: [PATCH v3 3/4] x86/mce, EDAC/mce_amd: Cache MCA_CONFIG[McaX] in struct mce

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] [day] [month] [year] [list]

Message-ID: <340dc083-683a-0f4b-0c58-62e86820a593@amd.com>
Date:   Wed, 23 Feb 2022 16:25:07 -0600
From:   "Koralahalli Channabasappa, Smita" <skoralah@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
        x86@...nel.org, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        James Morse <james.morse@....com>,
        Robert Richter <rric@...nel.org>,
        Yazen Ghannam <yazen.ghannam@....com>
Subject: Re: [PATCH v3 3/4] x86/mce, EDAC/mce_amd: Cache MCA_CONFIG[McaX] in
 struct mce_bank

On 2/22/22 3:15 PM, Borislav Petkov wrote:
> On Tue, Feb 22, 2022 at 02:47:44PM -0600, Koralahalli Channabasappa, Smita wrote:
>> But what do you think of severity? Will this make an impact when handling
>> panic severity levels? .. mce_severity_amd_smca().
> Well, look at the code: severity grading gets called when either polling
> or #MC handler gets to log an MCE. Reading an MSR costs a couple of
> hundred cycles. The whole MCE logging path costs maybe a couple of
> *orders* of magnitude more so that MSR read is in the noise when you
> have a 4GHz CPU executing 4 billion cycles per second.
>
> Now, that's for a single MCE.
>
> If it were more, say 10s, 100s, 1000s MCEs, then the MSR read is the
> least of your problems.
>
> But this is me conjecturing - I'm always interested in a real proof
> where it shows or it does not.
>
> I guess what I'm trying to say is, yeah, sure, speed is mostly a good
> argument. But you always need to consider at what cost you'd get that
> speed. And if at all. There are other important things like keeping the
> code base maintainable, readable and able to accept modifications for
> new features.
>
> So there's always this question of balance that needs to be asked...
>
Okay, this makes sense to me now. Thanks for the explanation. I will
drop this patch in the next series.

Thanks,
Smita