linux-kernel - Re: [PATCH 1/2] x86/MCE: Extend size of the MCE Records pool

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: <8d2d0dac-b188-4826-a43a-bb5fc0528f0d@amd.com>
Date: Fri, 9 Feb 2024 13:47:29 -0600
From: "Naik, Avadhut" <avadnaik@....com>
To: "Luck, Tony" <tony.luck@...el.com>, "x86@...nel.org" <x86@...nel.org>,
 "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Cc: "bp@...en8.de" <bp@...en8.de>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "yazen.ghannam@....com" <yazen.ghannam@....com>,
 Avadhut Naik <avadhut.naik@....com>
Subject: Re: [PATCH 1/2] x86/MCE: Extend size of the MCE Records pool

Hi,

On 2/8/2024 12:39, Luck, Tony wrote:
>> Will change it to (2 * sizeof(struct mce)) though. Feels more
>> accurate. Thanks for the suggestion!
> 
> Thanks.
> 
>> Do you have any additional concerns/comments on this patchset?
> 
> Overall this is an excellent addition. Reserved space to log errors does need to scale
> up with the CPU count.
> 
> I think part 1 (unconditional increase based on CPU count) is a "must have" enhancement.
> With the change to CPU_GEN_MEMSZ #define:
> 
> Reviewed-by: Tony Luck <tony.luck@...el.com>
> 
> 
> I'm less enthusiastic about part 2 adding a command line option to override the code in
> part 1 with a bigger (or smaller?) amount. Can you describe some situation where a user
> would need to use this?
> 
I added the command-line option to ensure that we have covered all bases and are not enforcing
this memory footprint on all users.

A system with 512 logical CPUs, by the current proposed logic, will have 32 pages allocated
for the pool ((512*256)/4096)). Some users may feel that this is not needed on their systems
and they can do with just, maybe, 16 pages. The command line option gives them the flexibility
to do so without having to change kernel code, rebuild and deploy.

Conversely, some users wanting to err on the side of caution, might feel that the above 32 pages
are not enough for the pool and may want to allocate more, maybe, 48 pages. The command line
option again, provides them with the flexibility to do so.

Sounds reasonable?

-- 
Thanks,
Avadhut Naik

> -Tony