linux-kernel - RE: [PATCH 6/7] EDAC/{skx_common,i10nm}: Refactor show_retry_rd_err

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: <DS7PR11MB60771225065A977E58A8E27EFCBF2@DS7PR11MB6077.namprd11.prod.outlook.com>
Date: Fri, 18 Apr 2025 15:25:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
CC: "Xu, Feng F" <feng.f.xu@...el.com>, Borislav Petkov <bp@...en8.de>, "James
 Morse" <james.morse@....com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
	Robert Richter <rric@...nel.org>, "Lai, Yi1" <yi1.lai@...el.com>, "Fan,
 Shawn" <shawn.fan@...el.com>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 6/7] EDAC/{skx_common,i10nm}: Refactor
 show_retry_rd_err_log()

> > Is there a mistake in the struct reg_rrl defintions where you intended to
> > have some "8" values somewhere?
>
> No, there isn't a mistake 😊.
>
> Currently, all CPUs EDAC supported by {skx,i10nm}_edac indeed just have the
> value "4" for "cecnt_widths".
>
> > Or is this just for symmetry with the ".widths" you have for the RRL register
> > (which do have varying widths).
>
> The upcoming CPU Diamond Rapids [1] will have the value "8" for "cecnt_widths".
> This is why I made the "cecnt_widths" field here, intended to easily cover this new
> CPU EDAC support in the future.
>
> Do you suggest not using the "cecnt_widths" field for now (since it currently only has
> the value 4 and the code appears somewhat redundant) until we add the EDAC support
> for Diamond Rapids in the future? Or we can keep the "cecnt_widths" field?

The general process is to avoid adding code/infrastructure for future use (as sometimes
that future never comes). But I have high hopes that Diamond Rapids will appear on
time. So I'll leave the cecnt_widths code in place. It's not much code.

> Either option is OK to me 😊.
>
> [1] https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/intel-family.h#L200

-Tony