diff options
author | Yanmin Zhang <yanmin_zhang@linux.intel.com> | 2008-06-30 18:21:54 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2008-07-02 20:46:16 -0700 |
commit | 712a9da4d9f05a918152422bbc30b601f892b62c (patch) | |
tree | d4ed9d02f14cf8a44d1a362464a1cbe9e458a693 /include/asm-x86/msr.h | |
parent | 66f100382995e2510e5bbae37ec4dbc4f73e4638 (diff) |
x86: fix cpu hotplug crash
Commit fcb43042ef55d2f46b0efa5d7746967cef38f056 upstream
x86: fix cpu hotplug crash
Vegard Nossum reported crashes during cpu hotplug tests:
http://marc.info/?l=linux-kernel&m=121413950227884&w=4
In function _cpu_up, the panic happens when calling
__raw_notifier_call_chain at the second time. Kernel doesn't panic when
calling it at the first time. If just say because of nr_cpu_ids, that's
not right.
By checking the source code, I found that function do_boot_cpu is the culprit.
Consider below call chain:
_cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
So do_boot_cpu is called in the end. In do_boot_cpu, if
boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later
on, when _cpu_up calls __raw_notifier_call_chain at the second time to
report CPU_UP_CANCELED, because this cpu is already cleared from
cpu_possible_map, get_cpu_sysdev returns NULL.
Many resources are related to cpu_possible_map, so it's better not to
change it.
Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in
cpu_possible_map.
Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com>
Tested-by: Vegard Nossum <vegard.nossum@gmail.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include/asm-x86/msr.h')
0 files changed, 0 insertions, 0 deletions