From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 4CA5A33A008 for ; Fri, 30 Jan 2026 11:33:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769772820; cv=none; b=JE0MzAopnecB/9Gtvuw4tlgu6ab55JGFQwfnOeQ0lRRK6LpAKvYhsBs/Sm7ooM6laeuydihP22LiKTtyS1kFxO7nhwxo+gTPspZPcFPOhNkxlrKHdFHt9pKiclo1eV9owEfzPNNHU000iMFTYvqNXbYrPdU6DA2oaeEl9UmXWUQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769772820; c=relaxed/simple; bh=Y61rIe7LL8lvW3DSlDD6UYeS98oipnZlEgPokAwySVc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Cs87ie2CzbB7VaP12kJ/N64RyIIrm76iI03VsQMRVUqoEBx996myUnqoUmqSQhr7DYPcTpA3b9u/hW9kKdGkObqJcJzo12KgoJSj9hT5bE9duI0uk8XJ8T2xy7rhvCLSpPRKIWTZWCw94cGLpwh8iju6MTSIcwMyR6bOlbvO3fU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=T8Wm9C5F; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="T8Wm9C5F" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Q4OqiaPkiDJxyRG/q0v5X8cfA51m/2cIfqGrbeL8ngI=; b=T8Wm9C5FOTGFJMKysnJDV1H+eX Iu3Fi58yp6gqD+BhfUrSh0j/uAOXNOMyQKLyaub6mKKxlA5VEO7ZUAF2nQzhxQ9Bavnd6vglXXyz6 nMVNzwKFbFNCYlAGjPX2BHsa8xRTA6n+QbFdlC04VAJh+WbZ+BzcF0ZflEc8HNQUFPKc4J7HNUsNC D6WqVIpJz3R8lbu234Dv003KdfAMgm7Znf77pcQroWUVIv6qLRmoEvkdP/40hZU+HO7NBtrpj0itO WPhSh08MheofBXJnO0zZx64fanr1m4Zs49kS3bdEbDeXdTYs6Iz+O2zQ07SsM702y3XcuYAa3L6Ko VOwqnE2w==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1vlmkl-001gPV-9Z; Fri, 30 Jan 2026 11:33:31 +0000 Date: Fri, 30 Jan 2026 03:33:25 -0800 From: Breno Leitao To: Andrew Morton 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: References: <20260129-vmcoreinfo_sysfs-v1-1-164c1fe1fe07@debian.org> <20260129142801.50781220e3164742a6e21858@linux-foundation.org> 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-Disposition: inline In-Reply-To: <20260129142801.50781220e3164742a6e21858@linux-foundation.org> X-Debian-User: leitao Hello Andrew, On Thu, Jan 29, 2026 at 02:28:01PM -0800, Andrew Morton wrote: > On Thu, 29 Jan 2026 05:34:10 -0800 Breno Leitao wrote: > > > 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. I'm fine with consolidating into a single line, though it would mean removing the timestamp of the last recovery event. Since the primary use case is tracking event counts in a time series, this is acceptable. My proposal: # cat /sys/kernel/hwerr_stats cpu:0 memory:2 pci:1 cxl:0 other:0 I suggest keeping the field names rather than dropping them entirely. While it would make the output more compact, having explicit names makes the format more maintainable when adding new recovery types in the future. Without names, it would look like: # cat /sys/kernel/hwerr_stats 0 2 1 0 0 What would you say? Thanks for reviewing it, --breno