Messages in this thread | | | Date | Tue, 24 Jun 2008 09:40:37 +0200 | From | "Vegard Nossum" <> | Subject | Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference |
| |
On Tue, Jun 24, 2008 at 3:36 AM, Rusty Russell <rusty@rustcorp.com.au> wrote: > Vegard's analysis is flawed: just because cpu is offline, it still must be < > nr_cpu_ids, which is based on possible cpus. Unless something crazy is > happening, but a quick grep doesn't reveal anyone manipulating nr_cpu_ids.
Hm, you are right and I was wrong. I'm sorry, it just seemed too obvious to be any other way, and I made some assumptions about nr_cpu_ids. (IIRC, nr_node_ids changes dynamically as nodes are added/removed, so I assumed it was the same for CPUs.)
This doesn't change the fact that get_cpu_sysdev(cpu) returns NULL, however. This variable, the per-cpu cpu_sys_device, is only ever changed in two places, register_cpu() and unregister_cpu(); in register_cpu(), it is set to
per_cpu(cpu_sys_devices, num) = &cpu->sysdev;,
and in unregister_cpu(), it is set to
per_cpu(cpu_sys_devices, logical_cpu) = NULL;.
So it seems *likely* that register_cpu() was never called (after the previous unregister_cpu(), which we know happened successfully).
register_cpu() is called from arch_register_cpu(), which is called from toplogy_init() and acpi_processor_hotadd_init(). Now, the topology_init() call-chain is uninteresting, since it only happens at boot. The question is whether acpi_processor_hotadd_init() will be called if the arch-specific __cpu_up() fails...
But I am not able to follow that code.
Thanks for looking at this.
Vegard
PS: I'll withdraw the statement that this is probably a regression. It seems more likely that nobody ever hit the "cpu failed to init" case before.
-- "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
| |