12:54 p.m.
----- "Bob Montgomery" <bob.montgomery(a)hp.com> wrote:
On Wed, 2009-11-11 at 14:52 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery(a)hp.com> wrote:
>
> > I have a dump from a 2.6.31-based x86_64 system where the number of
> > "possible" cpus equals the system's NR_CPUS (32).
> > On that system, the __per_cpu_offset table in the kernel consists of 32
> > valid offset pointers.
> I have a similar-but-different fix queued for this, but instead of
> checking for a NULL kt->__per_cpu_offset[i] entry, it changes the
> readmem() call to RETURN_ON_ERROR|QUIET instead of FAULT_ON_ERROR
> like this:
>
> if (!readmem(symbol_value("per_cpu__cpu_number") +
> kt->__per_cpu_offset[i],
> KVADDR, &cpunumber, sizeof(int),
> "cpu number (per_cpu)", QUIET|RETURN_ON_ERROR))
> break;
> That should prevent the failure you're seeing.
I did that first, and thought it was sort of cheating :-)
Sort of. But at that point in time we're still kind of blindly
wading around in the murk trying to figure out what we're
running on...
> 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?
So like this?
+ if (i && (kt->__per_cpu_offset[i] == NULL))
+ break;
Yes.
So it's always ok to try the readmem on the first element of
the array. And the RETURN_ON_ERROR would deal with something going
wrong with that, although that case would presumably be a real
problem with the dump, right? (cpus == 0)
Most likely yes. The motivation for my fix was due to a failure
attempting to readmem() a legitimate virtual address that was an
an excluded page from a makedumpfile-generated dump. If I recall
correctly, it was an in-house kexec-tools bugzilla, but I can't
find it.
Dave
4:32 p.m.
New subject: invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"
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.
5494
days inactive
5494
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Bob Montgomery -
Dave Anderson