[Crash-utility] Re: invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"

Dave Anderson anderson at redhat.com
Thu Nov 12 13:39:02 UTC 2009


----- "Bob Montgomery" <bob.montgomery at hp.com> 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
 





More information about the Crash-utility mailing list