linux-kernel - Re: [PATCH v3 4/6] x86/MCE: Make number of MCA banks per

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: <20190521202902.GC7793@cz.tnic>
Date:   Tue, 21 May 2019 22:29:02 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Ghannam, Yazen" <Yazen.Ghannam@....com>
Cc:     "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v3 4/6] x86/MCE: Make number of MCA banks per_cpu

On Tue, May 21, 2019 at 05:52:42PM +0000, Ghannam, Yazen wrote:
> This message comes from ___might_sleep() which checks the
> system_state.
>
> On CPU0, system_state=SYSTEM_BOOTING.
>
> On every other CPU, system_state=SYSTEM_SCHEDULING, and that's the
> only system_state where the message is shown.

Right, the check in ___might_sleep().

> Changing GFP_KERNEL to GFP_ATOMIC seems to be a fix. Is this
> appropriate? Or do you think there's something else we could try?

From: Documentation/core-api/memory-allocation.rst

  * If you think that accessing memory reserves is justified and the kernel
    will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.


I don't think the MCA banks representation justifies accessing memory
reserves.

Can we do instead:

-static DEFINE_PER_CPU_READ_MOSTLY(struct mce_bank *, mce_banks_array);
+static DEFINE_PER_CPU_READ_MOSTLY(struct mce_bank, mce_banks_array[MAX_NR_BANKS]);

which should be something like 9*32 = 288 bytes per CPU.

Unless you have a better idea...

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply. Srsly.