linux-kernel - Re: [PATCH v5 13/20] x86/mce: Unify AMD THR handler with MCA Polling

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: <20250902172543.GB273005@yaz-khff2.amd.com>
Date: Tue, 2 Sep 2025 13:25:43 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, Tony Luck <tony.luck@...el.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
	Smita.KoralahalliChannabasappa@....com,
	Qiuxu Zhuo <qiuxu.zhuo@...el.com>,
	Nikolay Borisov <nik.borisov@...e.com>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v5 13/20] x86/mce: Unify AMD THR handler with MCA Polling

On Tue, Sep 02, 2025 at 07:04:38PM +0200, Borislav Petkov wrote:
> On Tue, Sep 02, 2025 at 09:37:13AM -0400, Yazen Ghannam wrote:
> > This means we'd need to do another loop through the banks. Their
> > MCi_STATUS registers would be cleared. So they could log another error
> > before the limit is reset.
> > 
> > Overall, the goal is to loop through the banks one time and log/reset
> > banks as we go through them.
> 
> Is there anything special about keeping this looping once? I might've missed
> the reason if there were any particular one...
> 

Mostly for code reuse and so that user settings for polling will apply
to AMD systems.

Also, MCi_STATUS should be cleared as the last step. So it'd be more
efficient to do any logging/clearing/resetting of an MCA bank all
together.

> In any case, it sounds to me like you want a wrapper called
> 
> 	clear_bank(i)
> 
> which executes at the end of machine_check_poll() and hides in there all
> the possible MCA banks that need to be touched when done with the bank.
> 
> It'll still call back'n'forth through the code but at least all will be nicely
> abstracted and concentrated.
> 

Right, I had a similar idea earlier:
https://lore.kernel.org/all/20240523155641.2805411-7-yazen.ghannam@amd.com/

The callback function still referenced "threshold limit" so it wasn't
totally abstracted.

I can go back to this idea and make it more abstracted like you suggest.

Thanks,
Yazen