On Tue, Jul 07, 2026 at 09:02:47AM -0700, Borislav Petkov wrote:

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

quoted

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.

The current vmcoreinfo implementation defaults to enabled, so I wanted to
preserve that behavior to avoid silently removing symbols that existing
tools may depend on. Would you prefer a different default?

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

Will do.

quoted

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.

I agree the sysfs exposure duplicates existing infrastructure, points
taken. However, tracking fatal hardware errors provides value at crash
analysis time—it lets us quickly determine whether a fatal hardware
error occurred during the kernel's lifetime, which is useful for
root-cause attribution.

The stick-the-error-into-vmcore makes sense as a use case

For this, would you like to keep it in vmcore info (as of today), or
move to RAS subsystem?

Thanks for the review and direction,
--breno