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]

Date:   Sat, 18 May 2019 13:25:31 +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>,
        "bp@...e.de" <bp@...e.de>,
        "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, Apr 30, 2019 at 08:32:20PM +0000, Ghannam, Yazen wrote:
> From: Yazen Ghannam <yazen.ghannam@....com>
> 
> The number of MCA banks is provided per logical CPU. Historically, this
> number has been the same across all CPUs, but this is not an
> architectural guarantee. Future AMD systems may have MCA bank counts
> that vary between logical CPUs in a system.
> 
> This issue was partially addressed in
> 
> 006c077041dc ("x86/mce: Handle varying MCA bank counts")
> 
> by allocating structures using the maximum number of MCA banks and by
> saving the maximum MCA bank count in a system as the global count. This
> means that some extra structures are allocated. Also, this means that
> CPUs will spend more time in the #MC and other handlers checking extra
> MCA banks.

...

> @@ -1480,14 +1482,15 @@ EXPORT_SYMBOL_GPL(mce_notify_irq);
>  
>  static int __mcheck_cpu_mce_banks_init(void)
>  {
> +	u8 n_banks = this_cpu_read(mce_num_banks);
>  	struct mce_bank *mce_banks;
>  	int i;
>  
> -	mce_banks = kcalloc(MAX_NR_BANKS, sizeof(struct mce_bank), GFP_KERNEL);
> +	mce_banks = kcalloc(n_banks, sizeof(struct mce_bank), GFP_KERNEL);

Something changed in mm land or maybe we were lucky and got away with an
atomic GFP_KERNEL allocation until now but:

[    2.447838] smp: Bringing up secondary CPUs ...
[    2.456895] x86: Booting SMP configuration:
[    2.457822] .... node  #0, CPUs:        #1
[    1.344284] BUG: sleeping function called from invalid context at mm/slab.h:418
[    1.344284] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
[    1.344284] no locks held by swapper/1/0.
[    1.344284] irq event stamp: 0
[    1.344284] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
[    1.344284] hardirqs last disabled at (0): [<ffffffff8106bd36>] copy_process.part.59+0x676/0x1b60
[    1.344284] softirqs last  enabled at (0): [<ffffffff8106bd36>] copy_process.part.59+0x676/0x1b60
[    1.344284] softirqs last disabled at (0): [<0000000000000000>] 0x0
[    1.344284] Preemption disabled at:
[    1.344284] [<ffffffff81042a60>] start_secondary+0x50/0x170
[    1.344284] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.1.0+ #1
[    1.344284] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
[    1.344284] Call Trace:
[    1.344284]  dump_stack+0x67/0x9b
[    1.344284]  ___might_sleep+0x16c/0x250
[    1.344284]  __kmalloc+0x182/0x280
[    1.344284]  mcheck_cpu_init+0x1d9/0x430
[    1.344284]  identify_cpu+0x3e5/0x720
[    1.344284]  identify_secondary_cpu+0x13/0x80
[    1.344284]  smp_store_cpu_info+0x48/0x60
[    1.344284]  start_secondary+0x63/0x170
[    1.344284]  ? set_cpu_sibling_map+0x500/0x500
[    1.344284]  secondary_startup_64+0xa4/0xb0
[    2.587866]   #2  #3  #4
[    2.609287] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
[    2.618875]   #5  #6  #7
[    2.638092] smp: Brought up 1 node, 8 CPUs
[    2.639814] smpboot: Max logical packages: 4
[    2.640830] smpboot: Total of 8 processors activated (57466.51 BogoMIPS)

.config is attached and branch is at

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=rc0%2b3-ras

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

View attachment ".config" of type "text/plain" (119028 bytes)