Messages in this thread | | | Date | Thu, 24 Jul 2008 10:15:48 -0700 | From | Max Krasnyansky <> | Subject | Re: latest -git: kernel BUG at arch/x86/kernel/microcode.c:142! |
| |
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
| |