On Wed, 2009-11-11 at 18:54 +0000, Dave Anderson wrote: > > > But another question is in the (extremely) rare circumstance of a > > > non-CONFIG_SMP kernel. In that case, the kt->__per_cpu_offset[] array > > > would be all NULL, and the symbol_value("per_cpu__cpu_number") > > > call would return the qualified unity-mapped address. So the > > > virtual address calculation should work in x86_64_per_cpu_init(), > > > and the loop wouldn't even be entered in x86_64_get_smp_cpus() > > > > > > That being said, I don't think I've seen a recent x86_64 kernel > > > that was not compiled CONFIG_SMP, so I can't confirm that it's > > > ever been tested. > > > > > > So for sanity's sake, maybe your patch should also be applied, > > > but should also check if the "i" index is non-zero? Now I'm thinking that test won't be needed for the non-CONFIG_SMP kernel. If the array is full of 0x0s, the loop will compute the first address as (0x0 + symbol_value("per_cpu__cpu_number")) and read a cpunumber of 0. Then on the next iteration, it will calculate the very same address again, and read the same cpunumber of 0. But now the test is against cpus==1, so that test will fail and we'll drop out of the loop, right?

In the real smp case, we'll still try to read the small offset (cc08) like an address, but be spared any embarrassment by the QUIET| RETURN_ON_ERROR fix.