linux-kernel - RE: [PATCH] ghes: Track number of recovered hardware errors

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: <SJ1PR11MB6083D08A2F94FAEE5261AA6CFC50A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 18 Jul 2025 17:36:50 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Breno Leitao <leitao@...ian.org>, "xueshuai@...ux.alibaba.com"
	<xueshuai@...ux.alibaba.com>, "mahesh@...ux.ibm.com" <mahesh@...ux.ibm.com>,
	"oohall@...il.com" <oohall@...il.com>
CC: Borislav Petkov <bp@...en8.de>, "Rafael J. Wysocki" <rafael@...nel.org>,
	Len Brown <lenb@...nel.org>, James Morse <james.morse@....com>, "Moore,
 Robert" <robert.moore@...el.com>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "acpica-devel@...ts.linux.dev"
	<acpica-devel@...ts.linux.dev>, "kernel-team@...a.com"
	<kernel-team@...a.com>, "osandov@...ndov.com" <osandov@...ndov.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: RE: [PATCH] ghes: Track number of recovered hardware errors

> I found that I don't need to expose the metrics in vmcore info at all to
> be able to read them from vmcore, given crash/drgn can read those
> symbols.
>
> Global variable hwerror_tracking will be write-only during kernel
> run-time, and only read during post morten analyzes. I am still not sure
> if the compiler might not get rid of them completely, given no on reads.
> I am wondering if I should EXPORT_SYMBOL_GPL(hwerror_tracking) to avoid
> any optimization there.

Thanks for fleshing this out into a patch. It looks very much like I
imagined.

I'd be amazed if a compiler did elide all this code and data because it
noticed it was written but never read.

Is the spinlock when logging really helping anything? You weren't
worried about locking/atomics in your original patch because users
mostly care about zero vs. non-zero (or maybe vs. "many"). If the
count is slightly off when many logs happen, it may not matter.

The spinlock doesn't help with the timestamp part at all.

> Anyway, this is the patch I am using and it solves the problem I am
> interested in. Any opinion?

-Tony