On Tue, Jul 07, 2026 at 07:02:34AM -0700, Breno Leitao wrote:

The recoverable hardware error tracking (hwerr_log_error_type() and the
hwerr_data[] counters) was added under vmcoreinfo, but it uses none of the
vmcoreinfo note machinery: hwerr_data[] is a plain global array that crash
tools read from the vmcore by symbol, like any other global.  Functionally
it is RAS code, fed only by the hardware error paths (x86 MCE, APEI GHES
and PCIe AER).

I wanted to expand it, and Baoquan suggested moving it away from vmcore
info, which makes sense. [1]

Move the implementation to drivers/ras/hwerr_tracking.c and the
declaration (with its no-op stub) to <linux/ras.h>.  Give it a dedicated
CONFIG_RAS_HWERR (bool, under RAS, default y) rather than riding

Definitely not default y.

CONFIG_VMCORE_INFO, so it is a first-class RAS feature that can be turned
off on its own.  The producers now reach hwerr_log_error_type() through
<linux/ras.h>: x86 MCE and APEI GHES already include it, so drop their
<linux/vmcore_info.h> include; PCIe AER switches its include from
<linux/vmcore_info.h> to <linux/ras.h>.

enum hwerr_error_type stays in <uapi/linux/vmcore.h> as it has been part
of the UAPI since the feature shipped; <linux/ras.h> includes it from
there.

hwerr_data[] keeps its name and layout, so existing crash/drgn recipes
keep working.  The config gate moves from CONFIG_VMCORE_INFO to
CONFIG_RAS_HWERR (default y).

Do not explain the WHAT - that's visible from the diff below; explain the WHY.

Link: https://lore.kernel.org/all/aYvi4Y_HNqk_u1-v@fedora/ (local) [1]
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Once we move it outside of vmcore info, I am planning to add new
features that are in the limbo now, given they don't belong to vmcore
info, such as:

Track fatal hardware errors
	https://lore.kernel.org/all/20260617-hwerr-v1-0-ff131cd6203c@debian.org/ (local)

Expose hardware error recovery statistics via sysfs
	https://lore.kernel.org/all/20260202-vmcoreinfo_sysfs-v2-0-8f3b5308b894@debian.org/ (local)

We already have rasdaemon and a whole pile of infrastructure around reporting
errors. Why isn't what we have, enough?

The stick-the-error-into-vmcore makes sense as a use case, sure. But this
other information we already have plenty. I think you should use/extend that
instead of adding more.

Thx.

-- 
Regards/Gruss,
    Boris.

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