[Crash-utility] handling missing kdump pages in diskdump format

[Dave Anderson]

Bob Montgomery wrote:

> On Thu, 2007-03-29 at 08:13 -0500, Dave Anderson wrote:
> > Ken'ichi Ohmichi wrote:
>
> > > I checked whether this change is correct by the following:
> > > (The following patches are attached with this mail)
> > > - makedumpfile-1.1.2 with "point_same_zero_page2.patch" creates a dumpfile.
> > > - crash-4.0-3.21 with "not-access-excluded-page.patch" analyzes the dumpfile.
> > > - The analysis result of the dumpfile is compared with /proc/vmcore's.
> > >
> > > And on i386 linux-2.6.19, I found the difference between the result
> > > of the dumpfile (excluding free pages) and /proc/vmcore's by subcommand
> > > "foreach bt".
> > > But by using crash-4.0-3.21 without "not-access-excluded-page.patch",
> > > there is not any difference. In a word, this difference happens due to
> > > considering the excluded pages as unaccess pages.
>
> Just to clarify for those who probably aren't as confused as I was at
> first:
>
> This isn't a test of the zero page trick, because with the changes to
> makedumpfile, zero pages are no longer actually excluded.  (I read
> "excluding free pages" but immediately thought "excluding zero pages"
> and spent more than a few minutes checking how that could possibly have
> happened.)
>
> So this is apparently a case where a page excluded because it was
> supposedly free is then maybe accessed by the back tracer while it might
> be trying to read kernel text, right?  But kernel text should never look
> free, so I'm still puzzled.  Did makedumpfile mis-identify a real page
> as free, or is crash asking for pages it shouldn't be looking at during
> backtrace?
>

No -- it's kernel text that was marked as __init, so the page containing
it got freed and reallocated as a page that was purposely excluded.
The page originally contained the "start_kernel" __init function, which
only gets executed once by the first swapper thread.

The problem is that crash shouldn't be looking at that text location
when doing a backtrace on that PID 0, because it should have
stopped the trace as soon as it saw the "cpu_idle" stack reference.
I don't know why it's doing that -- I tried simulating Ken'ichi's vmcore
by forcibly returning an error if readmem() got a request for the
page originally containing "start_kernel", but the backtrace worked
OK -- even though I could see the "start_kernel" reference on
the stack when using "bt -t".

Anyway, that's why I've asked Ken'ichi if he can make his
vmlinux/vmcore pair available for me to debug.

Thanks,
  Dave



>
> Anyway, with my test dump on my x86_64 box, I don't get a case where
> dumpfiles with excluded free pages produce different "foreach bt" output
> than I get from the vmcore file.  I tried -d16 and -d31 options.  I do
> get the expected excluded page message when I x/xg an excluded address,
> just no problems with bt.  So I can't help Dave with an example.
>
> Bob Montgomery