From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18DBC32571F for ; Thu, 29 Jan 2026 22:28:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769725683; cv=none; b=hmhCABVOgWJ+LZdpfcg8TG/uuuJrQxHd0TCUscYSiAYyy1Yi57sw2u1jV4efPihNAYtKbZUJYc6xyPNj0qTjKoT88ETiLRUvbQXtEplG6vv8UDqyJ36gLwcbsoPfmV8XeLenm1lpBCu5ZTInx5Ar1LQiQXAxkxV+HvBEiVJGseg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769725683; c=relaxed/simple; bh=N44h9IGQl6Tlfza/FlS2ht0OSxdsGypVx/k58diTUgw=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=ZzTfMguJoqzZMXFDP1nVq6SaoEZmBwLk/+e3MWZmZd7aI4vPC6p7MHv7bVZl7Prr7wLFPWurJIDgTLNONptlkF0Pgfgo5SErN5I/3Fu+u9jcYbUDvQ4Iy9J8OsauZnVrJ4KUrUVVkU+9DTo0IlslC++JOCP8vfaWAFbv4V5YQyg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=eUpotNSl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="eUpotNSl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E8A6C4CEF7; Thu, 29 Jan 2026 22:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1769725682; bh=N44h9IGQl6Tlfza/FlS2ht0OSxdsGypVx/k58diTUgw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eUpotNSlwiEN0apH8/vUnPCrZAUNUEeLlAtcARF3P2459HK+4tEj9lF2PMC3QhPMY YW79aOx/OK0a0pgBBrG7Y3hzhhECleRAm4QHttVhEbodm2rCll5bOINglXlHCgTB/9 4uW4VmxR2Rg6ffEuGg2H1R/Gf+FK2sxum9uxBVX0= Date: Thu, 29 Jan 2026 14:28:01 -0800 From: Andrew Morton To: Breno Leitao Cc: bhe@redhat.com, linux-kernel@vger.kernel.org, kernel-team@meta.com, kexec@lists.infradead.org, dyoung@redhat.com, tony.luck@intel.com, xueshuai@linux.alibaba.com, vgoyal@redhat.com, zhiquan1.li@intel.com, olja@meta.com Subject: Re: [PATCH] vmcore_info: expose hardware error recovery statistics via sysfs Message-Id: <20260129142801.50781220e3164742a6e21858@linux-foundation.org> In-Reply-To: <20260129-vmcoreinfo_sysfs-v1-1-164c1fe1fe07@debian.org> References: <20260129-vmcoreinfo_sysfs-v1-1-164c1fe1fe07@debian.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 29 Jan 2026 05:34:10 -0800 Breno Leitao 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)); > +} > + > > ... >