linux-kernel - Re: [PATCH v3 17/17] x86/mce: Restore poll settings after storm subsides

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: <20250513210640.GA515295@yaz-khff2.amd.com>
Date: Tue, 13 May 2025 17:06:40 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, Tony Luck <tony.luck@...el.com>,
	linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
	Smita.KoralahalliChannabasappa@....com,
	Qiuxu Zhuo <qiuxu.zhuo@...el.com>
Subject: Re: [PATCH v3 17/17] x86/mce: Restore poll settings after storm
 subsides

On Tue, May 13, 2025 at 07:55:43PM +0200, Borislav Petkov wrote:
> On Mon, May 12, 2025 at 11:43:15AM -0400, Yazen Ghannam wrote:
> > The use case is "disable MCA polling". I just gave two examples of how
> > this can be done.
> 
> Our documentation says:
> 
>                 ignore_ce
>                         disable features for corrected errors, e.g.
>                         polling timer and CMCI.  All events reported as 
>                         corrected are not cleared by OS and remained in its
>                         error banks.
> 
>                         Usually this disablement is not recommended, however
>                         if there is an agent checking/clearing corrected
>                         errors (e.g. BIOS or hardware monitoring 
>                         applications), conflicting with OS's error handling,
>                         and you cannot deactivate the agent, then this option
>                         will be a help.
> 
> it basically disables all: polling *and* CMCI.
> 
> So why do we even bother with storms?
> 

I think I see your point. The AMD MCA Thresholding init flow doesn't
check "ignore_ce". We should fix that to have more feature parity
between vendors.

Another item for the to do list. :)

> > We can focus on "check_interval=0". The user wants to disable MCA
> > polling and rely only on interrupts. They still want to see the CEs.
> 
> Is that a use case we support?
> 
> Where is that documented?
> 
> I can see why someone would want to avoid the recurrent polling but I'm not
> sure we explicitly say that somewhere in the text...
> 

Right, good point. This may come down to another vendor difference.

On Intel, the set of banks for polling and for CMCI are mutually
exclusive. So polling can be effectively disabled if all banks support
CMCI.

On AMD, polling and interrupt are independent. We still poll all banks
even if they are interrupt-capable. I think we discussed this in a
previous revision of this set.

So I think we should document this use case. And also consider changing
the polling/interrupt behavior on AMD. Even if this use case is
documented, it still requires user intervention which we can avoid if we
change the kernel behavior.

> > When the storm ends, the kernel should go back to how things were before
> > the storm. If there was a timer before, then go back to the old
> > interval. If there was *not* a timer before, then delete/remove the
> > timer.
> 
> That I agree with.
> 

Okay.

Thanks,
Yazen