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]
Date:   Wed, 23 Sep 2020 10:20:39 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Yazen Ghannam <Yazen.Ghannam@....com>
Cc:     linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
        tony.luck@...el.com, x86@...nel.org,
        Smita.KoralahalliChannabasappa@....com
Subject: Re: [PATCH v2 8/8] x86/MCE/AMD Support new memory interleaving modes
 during address translation

On Thu, Sep 03, 2020 at 08:01:44PM +0000, Yazen Ghannam wrote:
> From: Muralidhara M K <muralidhara.mk@....com>
> 
> Add support for new memory interleaving modes used in current AMD systems.
>
> Check if the system is using a current Data Fabric version or a legacy
> version as some bit and register definitions have changed.
> 
> Tested on AMD reference platforms with the following memory interleaving
> options.
> 
> Naples
> - None
> - Channel
> - Die
> - Socket
> 
> Rome (NPS = Nodes per Socket)
> - None
> - NPS0
> - NPS1
> - NPS2
> - NPS4
> 
> The fixes tag refers to the commit that allows amd64_edac_mod to load on
> Rome systems.

Err, why? This is adding new stuff to an address translation function.
How does that fix amd64_edac loading on Rome?

> The module may report an incorrect system addresses on
> Rome systems depending on the interleaving option used.

That doesn't stop it from loading, sorry.

Now, before you guys do any new features, I'd like you to split this
humongous function umc_normaddr_to_sysaddr() logically into separate
helpers and each helper does exactly one thing and one thing only.

Then use a verb in its name: umc_translate_normaddr_to_sysaddr() or so.

Also, Yazen, remind me again pls why isn't this function in
drivers/edac/amd64_edac.c, where it is needed?

If the reason is not valid anymore, let's move it there before splitting
so that it doesn't bloat the core code.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ