Re: [Crash-utility] strange kdump vmcore PT_LOAD segments

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