Messages in this thread | | | Date | Mon, 30 Jun 2008 13:19:07 +0200 | From | Ingo Molnar <> | Subject | Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference |
| |
* Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Tuesday 24 June 2008 18:06:23 Zhang, Yanmin wrote:
> > 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 source codes, I find 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. > > > > Vegard, would you like to help test it? > > > > Signed-off-by: Zhang Yanmin <yanmin_zhang@linux.intel.com> [...]
> Nice catch. Basically, cpu_possible_map should only be cleared at > boot, and probably not even then. > > Acked-by: Rusty Russell <rusty@rustcorp.com.au>
applied to tip/x86/urgent for v2.6.26 merging - thanks everyone!
Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |