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

[Bob Montgomery]

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?

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