Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference

[Vegard Nossum]

On Tue, Jun 24, 2008 at 10:06 AM, Zhang, Yanmin
<yanmin_zhang@xxxxxxxxxxxxxxx> 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.

Ahhha! Well done!

(Whew, I have a lot to learn :-D)

>
> 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?

Sure, but it can take a while. 1) I have no idea why the processor
failed to initialize in the first place. So far, it only ever happened
this one time. 2) There seems to be a couple of other failure cases
related to cpu hotplug (usually the machine freezes hard), so it's not
certain that we hit this (failed to initialize) first. But I will try!

Thanks for solving the mystery.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
¢éì®&Þ~º&¶¬–+-±éÝ¥Šw®žË±Êâmébžìdz¹Þ)í…æèw*jg¬±¨¶‰šŽŠÝj/êäz¹ÞŠà2ŠÞ¨è­Ú&¢)ß«a¶Úþø®G«éh®æj:+v‰¨Šwè†Ù>Wš±êÞiÛaxPjØm¶ŸÿÃ-»+ƒùdš_