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/ [1] > Signed-off-by: Breno Leitao <[email protected]> > --- > 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/[email protected]/ > > Expose hardware error recovery statistics via sysfs > > https://lore.kernel.org/all/[email protected]/ 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
