On Mon, Jul 14, 2025 at 03:21:44PM -0700, Luck, Tony wrote:
> On Mon, Jul 14, 2025 at 07:35:56PM +0200, Borislav Petkov wrote:
> > On Mon, Jul 14, 2025 at 05:33:45PM +0000, Luck, Tony wrote:
> > > > If you're going to do this, then you can perhaps make this variable always
> > > > present so that you don't need an export and call it "hardware_errors_count"
> > > > or so and all machinery which deals with RAS - GHES, MCE, AER, bla, can
> > > > increment it...
> > >
> > > Not sure I'd want to see all the different classes of errors bundled together
> > > in a single count. I think MCE recovery is quite robust and rarely leads to
> > > subsequent kernel problems.
> >
> > That's what I said. And a RAS tool can give that info already.
>
> There's some value in it being in the kdump file, rather than having
> to correlate data from multiple places. That's both time consuming
> and error prone.
That's precisely the aim: I want to streamline the process without
duplicating detailed error reports, since we already have specialized
tools for in-depth analysis.
Even a brief value in the crash dump alerting the reader that errors
occurred would be a valuable aid for anyone diagnosing the issue.
> > But for some reason Breno still wants that info somewhere else.
>
> So what about something like:
>
> enum recovered_error_sources {
> ERR_GHES,
> ERR_MCE,
> ERR_AER,
> ...
> ERR_NUM_SOURCES
> };
>
> static struct recovered_error_info {
> int num_recovered_errors;
> time64_t last_recovered_error_timestamp;
> } recovered_error_info[ERR_NUM_SOURCES];
>
> void log_recovered_error(enum recovered_error_sources src)
> {
> recovered_error_info[src].num_recovered_errors++;
> recovered_error_info[src].last_recovered_error_timestamp =
> ktime_get_real_seconds();
> }
> EXPORT_SYMBOL_GPL(log_recovered_error);
>
>
> PLus code to include that in VMCORE.
>
> Then each subsystem just adds:
>
>
> log_recovered_error(ERR_GHES);
> or
> log_recovered_error(ERR_MCE);
> etc.
>
> in the recovery path.
Thanks. Let me play with this suggestion.
--breno
