Messages in this thread | | | From | Rusty Russell <> | Subject | Re: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference | Date | Tue, 24 Jun 2008 11:36:51 +1000 |
| |
On Tuesday 24 June 2008 02:58:44 Mike Travis wrote: > Rusty Russell wrote: > > On Monday 23 June 2008 02:29:07 Vegard Nossum wrote: > >> And the (cpu < nr_cpu_ids) fails because the CPU has just been > >> offlined (or failed to initialize, but it's the same thing), while > >> NR_CPUS is the value that was compiled in as CONFIG_NR_CPUS (so the > >> former check will always be true). > >> > >> I don't think it is valid to ask for a per_cpu() variable on a CPU > >> which does not exist, though > > > > Yes it is. As long as cpu_possible(cpu), per_cpu(cpu) is valid. > > > > The number check should be removed: checking cpu_possible() is > > sufficient. > > > > Hope that helps, > > Rusty. > > I don't see a check for index being out of range in cpu_possible().
You're right. It assumes cpu is < NR_CPUS. Hmm, I have no idea what's going on. nr_cpu_ids (ignore that it's a horrible name for a bad idea) should be fine to test against.
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.
If changing this fixes the bug, something else is badly wrong... Rusty.
| |