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

[Max Krasnyansky <maxk@qualcomm.com>]

Dmitry Adamushko wrote:
> 2008/7/24 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> 2008/7/24 Vegard Nossum <vegard.nossum@gmail.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@qualcomm.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