----- "Bob Montgomery" <bob.montgomery@xxxxxx> wrote:
> 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?
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.
Just to be clear, I think that we agree that:
(1) the QUIET|RETURN_ON_ERROR be applied in both functions,
(2) the kt->__per_cpu_offset[] NULL-check should be completely dropped
in x86_64_per_cpu_init(), and
(3) the kt->__per_cpu_offset[] NULL-check should still be applied in
x86_64_get_smp_cpus() since that loop pre-requires that it's SMP.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
