linux-kernel - Re: latest -git: kernel BUG at arch/x86/kernel/microcode.c:142!

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] [day] [month] [year] [list]

Date:	Thu, 24 Jul 2008 10:15:48 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
CC:	Vegard Nossum <vegard.nossum@...il.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Mike Travis <travis@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Gregory Haskins <ghaskins@...ell.com>, pj@....com,
	Ingo Molnar <mingo@...e.hu>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Shaohua Li <shaohua.li@...el.com>
Subject: Re: latest -git: kernel BUG at arch/x86/kernel/microcode.c:142!

Dmitry Adamushko wrote:
> 2008/7/24 Dmitry Adamushko <dmitry.adamushko@...il.com>:
>> 2008/7/24 Vegard Nossum <vegard.nossum@...il.com>:
>>>> It's this one:
>>>>
>>>>        /* We should bind the task to the CPU */
>>>>        BUG_ON(raw_smp_processor_id() != cpu_num);
>>>>
>>>> Maybe related to recently merged per-cpu changes? (Yesterday's tests ran fine.)
>>>>
>>>> It seems 100% reproducible, so I'll start bisecting it.
>>> Ahha, after many hours of hitting various unrelated crashes,
>>> miscompiles, etc. I finally arrive at this commit:
>>>
>>> commit e761b7725234276a802322549cee5255305a0930
>>> Author: Max Krasnyansky <maxk@...lcomm.com>
>>> Date:   Tue Jul 15 04:43:49 2008 -0700
>> Yeah, there seems to be a funny situation here :-) I'd expect it to be
>> 100% reproduceable with CONFIG_MICROCODE=y.
>>
>> cpu_up() -> raw_notifier_call_chain(CPU_ONLINE, ...) ->
>>
>> (microcode's part)
>>
>> mc_cpu_callback() -> mc_sysdev_add() -> microcode_init_cpu()
>>
>> and here we have:
>>
>>        set_cpus_allowed_ptr(current, &cpumask_of_cpu(cpu));
> 
> btw., this is obviously bad behavior. This code plays with
> "cpus_allowed" (changes and then restores it) of pretty arbitrary
> tasks in context of which it happens to run. So it may race with
> sched_setaffinity() and negate its effect.

Agree. I came to the similar conclusion.
The solution is to either convert it to schedule_delayed_work_on() or if it's
important to update the microcode synchronously we can the whole thing to do
something like
	smp_call_function_single(cpu, collect_cpu_info);
	if (needs_update) {
		request_firmware(...);
		smp_call_function_single(cpu, update_cpu_microcode);
	}

Tigran, do we need sync update inside the hotplug handler or async update via
workqueue is fine ?

Max


Max







--
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/