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.
At least that's how it looked when I tried to explain it at lunch :-)
Bob M.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
