Revision fcb43042ef55d2f46b0efa5d7746967cef38f056 authored by Zhang, Yanmin on 24 June 2008, 08:06:23 UTC, committed by Ingo Molnar on 30 June 2008, 11:15:43 UTC
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>
1 parent 0b1faee
History
File Mode Size
Documentation
arch
block
crypto
drivers
fs
include
init
ipc
kernel
lib
mm
net
samples
scripts
security
sound
usr
virt
.gitignore -rw-r--r-- 701 bytes
.mailmap -rw-r--r-- 3.6 KB
COPYING -rw-r--r-- 18.3 KB
CREDITS -rw-r--r-- 90.5 KB
Kbuild -rw-r--r-- 2.4 KB
MAINTAINERS -rw-r--r-- 98.1 KB
Makefile -rw-r--r-- 53.8 KB
README -rw-r--r-- 16.5 KB
REPORTING-BUGS -rw-r--r-- 3.1 KB

README

back to top