[Crash-utility] strange kdump vmcore PT_LOAD segments

[Dave Anderson]

Looking into this a bit more, in the x86_64 case, it looks
to be harmless if the p_filesz is non-page-aligned.  For
example, we can see such a situation in the /proc/iomem of
a live x86_64 system, and reflected in its e820 map.  However,
the last, "truncated", page in the segment will not be used
by the kernel.  However, kdump will in fact copy the contents
of the truncated page.  Probably not a big deal...

For example, on my x86_64 box, /proc/iomem shows this:

  $ cat /proc/iomem | grep "System RAM"
  00000000-0009ffff : System RAM
  00100000-3fe8abff : System RAM
  $

The e820 map reflect this:

  crash> mach -m
        PHYSICAL ADDRESS RANGE         TYPE
  0000000000000000 - 00000000000a0000  E820_RAM
  00000000000f0000 - 0000000000100000  E820_RESERVED
  0000000000100000 - 000000003fe8ac00  E820_RAM
  000000003fe8ac00 - 000000003fe8cc00  E820_NVS
  000000003fe8cc00 - 000000003fe8ec00  E820_ACPI
  000000003fe8ec00 - 0000000040000000  E820_RESERVED
  00000000e0000000 - 00000000f0000000  E820_RESERVED
  00000000fec00000 - 00000000fed00400  E820_RESERVED
  00000000fed20000 - 00000000feda0000  E820_RESERVED
  00000000fee00000 - 00000000fef00000  E820_RESERVED
  00000000ffb00000 - 0000000100000000  E820_RESERVED

But it is impossible on this live system to read the page
that contains the ending physical address of 3fe8ac00:

  crash> rd -p 3fe8a000
  rd: read error: physical address: 3fe8a000  type: "64-bit PHYSADDR"

The page prior to that can be read OK:

  crash> rd -p 3fe89000
          3fe89000:  ffffffff803de258                    X.=.....

Of course in this case, the kernel "ends" there:

  crash> p high_memory
  high_memory = $1 = (void *) 0x1003fe8a000

...so the page doesn't even exist as far as the kernel
is concerned.

Now, looking at Badari's x86_64 kdump vmcore, it is
possible to access the memory right up to, but not
including, the last byte in the segment ending at
physical address d7fcca80:

  crash> mach -m
        PHYSICAL ADDRESS RANGE         TYPE
  0000000000000000 - 000000000009dc00  E820_RAM
  000000000009dc00 - 00000000000a0000  E820_RESERVED
  00000000000e0000 - 0000000000100000  E820_RESERVED
  0000000000100000 - 00000000d7fcca80  E820_RAM
  00000000d7fcca80 - 00000000d7fd0000  E820_ACPI
  00000000d7fd0000 - 00000000d8000000  E820_RESERVED
  00000000fec00000 - 0000000100000000  E820_RESERVED
  0000000100000000 - 0000000128000000  E820_RAM

  crash> rd -8 -p d7fcca80
  rd: read error: physical address: d7fcca80  type: "8-bit PHYSADDR"
  crash> rd -8 -p d7fcca7f
          d7fcca7f:  00                                                .
  crash>

But the kernel would never make use of the half-baked page
at physical address d7fcc000.  So, it also looks to be harmless
in this case.

What's not harmless, however, would be what's being
seen in Dave Wilder's ppc64 vmcore, where a segment's
starting p_paddr is non-page-aligned.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060504/300ee2c6/attachment.htm>