linux-kernel - Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutex deadlock (x86_cpu_hotplug_driver

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, 8 May 2013 14:54:14 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, fenghua.yu@...el.com,
	xen-devel@...ts.xensource.com
Subject: Re: v3.9 - CPU hotplug and microcode earlier loading hits a mutex
 deadlock (x86_cpu_hotplug_driver_mutex)

On Tue, May 07, 2013 at 03:00:24PM -0400, Konrad Rzeszutek Wilk wrote:
> I dug deeper in how QEMU does it and it looks to be actually doing
> the right thing. It triggers the ACPI SCI, the method that figures
> out the CPU online/offline bits kicks off the right OSPM notification
> and everything is going through ACPI (so _STA is on the processor is
> checked, returns 0x2 (ACPI_STA_DEVICE_PRESENT), MADT has now the CPU
> marked as enabled).

AFAIUC, you mean physical hotplug here which is done with ACPI, right?
And, if so, we actually need an x86 machine which supports that to test
it on. Also, is this how physical hotplug is done? Put the number of
max. supported CPUs in MADT and those which are not present are marked
as disabled?

Then, when they're physically hotplugged, ACPI marks them as enabled?
Questions over questions...?

> I am now 99% sure you would be able to reproduce this on baremetal with
> ACPI hotplug where the CPUs at bootup are marked as disabled in MADT.
> (lapic->lapic_flags == 0).
> 
> The comment for calling save_mc_for_early says:

Looks like save_mc_for_early would need another, local mutex to fix that.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/