Re: [PATCH RFC] RAS: hwerr_tracking: move recoverable hardware error tracking out of vmcoreinfo

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] The official documentation for hardware recoverable error tracking was not updated to reflect the new configuration gate and conceptual location.

Pre-existing issues:
- [High] Calling ktime_get_real_seconds() from NMI context causes a permanent seqcount deadlock on 32-bit platforms.
--

--- Patch [1]: [PATCH RFC] RAS: hwerr_tracking: move recoverable hardware error tracking out of vmcoreinfo ---
commit 1752de8824c67025df12b2ca7f3f5aa9d829d649
Author: Breno Leitao <leitao@debian.org>

RAS: hwerr_tracking: move recoverable hardware error tracking out of vmcoreinfo

This patch moves recoverable hardware error tracking out of vmcoreinfo
and into a dedicated RAS tracking file. It introduces CONFIG_RAS_HWERR
to allow independent configuration and updates included paths for callers.

Link: https://lore.kernel.org/all/aYvi4Y_HNqk_u1-v@fedora/ [1]

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 15011f5752a99..eee6072dc28f2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -22536,6 +22536,13 @@ L:	linux-edac@vger.kernel.org
>  S:	Maintained
>  F:	drivers/ras/amd/fmpm.c
>  
> +RAS RECOVERABLE HARDWARE ERROR TRACKING
> +M:	Breno Leitao <leitao@kernel.org>
> +L:	linux-edac@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/driver-api/hw-recoverable-errors.rst

[Severity: Low]
Does this patch miss updating the documentation? 

The commit moves the configuration gate from CONFIG_VMCORE_INFO to a new
dedicated CONFIG_RAS_HWERR, and extracts the feature from vmcoreinfo.
However, Documentation/driver-api/hw-recoverable-errors.rst is not updated
in this patch to reflect the new Kconfig dependencies and conceptual
location.

[ ... ]

> diff --git a/drivers/ras/hwerr_tracking.c b/drivers/ras/hwerr_tracking.c
> new file mode 100644
> index 0000000000000..847c01fb24d55
> --- /dev/null
> +++ b/drivers/ras/hwerr_tracking.c
> @@ -0,0 +1,35 @@
[ ... ]
> +void hwerr_log_error_type(enum hwerr_error_type src)
> +{
> +	if (src < 0 || src >= HWERR_RECOV_MAX)
> +		return;
> +
> +	atomic_inc(&hwerr_data[src].count);
> +	WRITE_ONCE(hwerr_data[src].timestamp, ktime_get_real_seconds());

[Severity: High]
This is a pre-existing issue, but can calling ktime_get_real_seconds() from
an NMI context cause a permanent seqcount deadlock on 32-bit platforms?

If a hardware error triggers an NMI (such as x86 Machine Check or APEI
GHES), hwerr_log_error_type() is called to record the error. On 32-bit
architectures, reading the 64-bit time requires a seqcount retry loop:

kernel/time/timekeeping.c:ktime_get_real_seconds() {
    ...
    do {
        seq = read_seqcount_begin(&tk_core.seq);
        seconds = tk->xtime_sec;
    } while (read_seqcount_retry(&tk_core.seq, seq));
    ...
}

If the NMI interrupts a timekeeping update on the exact same CPU, the
sequence counter is odd, and the read side will spin indefinitely waiting
for it to become even. Since the interrupted writer is preempted on the same
CPU, it can never progress, resulting in a hard deadlock.

Would it be safer to use an NMI-safe API such as ktime_get_real_fast_ns()
to prevent a recoverable error from causing a system freeze?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-hwerr-ras-v1-1-4aea4a79d085@debian.org?part=1