[Crash-utility] Kernel pages reported as PAGE_EXCLUDED

[Dave Anderson]

----- Original Message -----

> > In order to understand this error better I took a look at
> > diskdump.c:read_diskdump():
> > 
> >   if (!page_is_dumpable(pfn)) {
> >           if ((dd->flags & (ZERO_EXCLUDED|ERROR_EXCLUDED)) ==
> >               ERROR_EXCLUDED) {
> >                   if (CRASHDEBUG(8))
> >                           fprintf(fp, "read_diskdump: PAGE_EXCLUDED: "
> >                               "paddr/pfn: %llx/%lx\n",
> >                                   (ulonglong)paddr, pfn);
> >                   return PAGE_EXCLUDED;
> >           }
> >           if (CRASHDEBUG(8))
> >                   fprintf(fp, "read_diskdump: zero-fill: "
> >                       "paddr/pfn: %llx/%lx\n",
> >                           (ulonglong)paddr, pfn);
> >           memset(bufptr, 0, cnt);
> >           return cnt;
> >   }
> > 
> > Does this mean these kernel pages are *not* zero?
> 
> No, it means that if you invoke crash with the --zero_excluded flag,
> if an excluded page is encountered during runtime, it will return
> a zero-filled page instead of erroring out.

Stefan,

Sorry -- I misunderstood the question, and my response is irrelevant/misleading.

The answer to the question is actually:  not necessarily...

Here's why:

The compressed kdump dumpfile header contains a per-page bitmap
for the crashed kernel's maximum memory size:  

- If a page's bit is set to 1, then that page also has a small 
  page descriptor structure, which in turn points to the page's
  contents in the dumpfile.

- If a page's bit is set to 0, the page is excluded.  If an attempt
  is made to read the page, page_is_dumpable() will return FALSE,
  and the command will fail with an error message that indicates: 
  "<command>: page excluded: <memory type> <address> ..."

When a compressed kdump has been filtered based upon the
"makedumpfile -d <dump_level>" setting, these 5 page types
may be configured:

 #define DL_EXCLUDE_ZERO         (0x001) /* Exclude Pages filled with Zeros */
 #define DL_EXCLUDE_CACHE        (0x002) /* Exclude Cache Pages without Private Pages */
 #define DL_EXCLUDE_CACHE_PRI    (0x004) /* Exclude Cache Pages with Private Pages */
 #define DL_EXCLUDE_USER_DATA    (0x008) /* Exclude UserProcessData Pages */
 #define DL_EXCLUDE_FREE         (0x010) /* Exclude Free Pages */

When makedumpfile does the filtering, it first checks the configuration
of the DL_EXCLUDE_CACHE, DL_EXCLUDE_CACHE_PRI, DL_EXCLUDE_USER_DATA
and DL_EXCLUDE_FREE settings, the relevant pages will not be copied
to the dumpfile, and so their bitmap bits will be set to 0.

After the 4 DL_EXCLUDE_xxx pages above have been filtered, the DL_EXCLUDE_ZERO 
configuration is handled, and the remaining pages will be checked whether
they are zero-filled.  If so, their bitmap bits will be set to 1, but 
their page descriptors will all point to single, common, zero-filled
page in the dumpfile.

So getting back to the question:

> > Does this mean these kernel pages are *not* zero?

The reason the answer is "not necessarily" is because it is highly
likely that a zero-filled page may have been pre-filtered by one of the
other DL_EXCLUDE_xxx bits, and therefore it would have been excluded
prior to the subsequent DL_EXCLUDE_ZERO check.

And again, the --zero_excluded flag allows a crash user to prevent
a command from failing due to an excluded page.  But the result of
doing so is also completely unpredictable, so it should only be used
with care and understanding...

Dave