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: > > 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. > > 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. 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
