linux-kernel - Re: [PATCH] vmcore_info: expose hardware error recovery statistics via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260129142801.50781220e3164742a6e21858@linux-foundation.org>
Date: Thu, 29 Jan 2026 14:28:01 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Breno Leitao <leitao@...ian.org>
Cc: bhe@...hat.com, linux-kernel@...r.kernel.org, kernel-team@...a.com,
 kexec@...ts.infradead.org, dyoung@...hat.com, tony.luck@...el.com,
 xueshuai@...ux.alibaba.com, vgoyal@...hat.com, zhiquan1.li@...el.com,
 olja@...a.com
Subject: Re: [PATCH] vmcore_info: expose hardware error recovery statistics
 via sysfs

On Thu, 29 Jan 2026 05:34:10 -0800 Breno Leitao <leitao@...ian.org> wrote:

> Add a sysfs file at /sys/kernel/vmcore_stats and expose hardware error
> recovery statistics that are already tracked by the kernel. This allows
> userspace monitoring tools to track recovered hardware errors without
> requiring kernel crashes.
> 
> This is useful to track recoverable hardware errors in a time series,
> even if the host doesn't crash.
> 
> Create a generic vmcore_stats sysfs, and add a section for
> hwerr_recovery that shows the counts per subsystem and timestamps:
> 
>   - cpu: CPU-related errors (MCE, ARM processor errors)
>   - memory: Memory-related errors
>   - pci: PCI/PCIe AER non-fatal errors
>   - cxl: CXL errors
>   - other: Other hardware errors
> 
> Example output:
>   hwerr_recovery:
>     cpu: 0 (0)
>     memory: 2 (1738148257)
>     pci: 1 (1738147000)
>     cxl: 0 (0)
>     other: 0 (0)

sysfs rules (which are widely ignored) say "one value per file".

As a compromise the above could be squished into a single line.  Harder
for humans to read, but it sounds like that isn't the expected use case.

Or screw sysfs rules ;)

> The value in parentheses is the timestamp (seconds since epoch) of the
> last error of that type, or 0 if no errors have occurred.
> 
> These statistics provide visibility into the health of the system's
> hardware and can be used by system administrators to proactively detect
> failing components before they cause system crashes.
> 
> ...
>
> +/* sysfs interface for hardware error recovery statistics */
> +static ssize_t vmcore_stats_show(struct kobject *kobj,
> +				 struct kobj_attribute *attr, char *buf)
> +{
> +	return sysfs_emit(buf,
> +			  "Recovered hardware errors:\n"
> +			  "  cpu: %d (%lld)\n"
> +			  "  memory: %d (%lld)\n"
> +			  "  pci: %d (%lld)\n"
> +			  "  cxl: %d (%lld)\n"
> +			  "  other: %d (%lld)\n",
> +			  atomic_read(&hwerr_data[HWERR_RECOV_CPU].count),
> +			  (long long)READ_ONCE(hwerr_data[HWERR_RECOV_CPU].timestamp),
> +			  atomic_read(&hwerr_data[HWERR_RECOV_MEMORY].count),
> +			  (long long)READ_ONCE(hwerr_data[HWERR_RECOV_MEMORY].timestamp),

vsprintf has `%ptT' for time64_t.  Is it usable here?

> +			  atomic_read(&hwerr_data[HWERR_RECOV_PCI].count),
> +			  (long long)READ_ONCE(hwerr_data[HWERR_RECOV_PCI].timestamp),
> +			  atomic_read(&hwerr_data[HWERR_RECOV_CXL].count),
> +			  (long long)READ_ONCE(hwerr_data[HWERR_RECOV_CXL].timestamp),
> +			  atomic_read(&hwerr_data[HWERR_RECOV_OTHERS].count),
> +			  (long long)READ_ONCE(hwerr_data[HWERR_RECOV_OTHERS].timestamp));
> +}
> +
>
> ...
>