Re: latest -git: kernel BUG at arch/x86/kernel/microcode.c:142!
From: Max Krasnyansky
Date: Thu Jul 24 2008 - 13:16:18 EST
Dmitry Adamushko wrote:
> 2008/7/24 Dmitry Adamushko <dmitry.adamushko@xxxxxxxxx>:
>> 2008/7/24 Vegard Nossum <vegard.nossum@xxxxxxxxx>:
>>>> 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@xxxxxxxxxxxx>
>>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/