Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
makedumpfile (Debian) |
Fix Released
|
Unknown
|
|||
makedumpfile (Ubuntu) |
Fix Released
|
Medium
|
Ioanna Alifieraki | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Bionic |
Fix Released
|
Medium
|
Unassigned | ||
Eoan |
Fix Released
|
Medium
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Unassigned | ||
Groovy |
Fix Released
|
Medium
|
Ioanna Alifieraki |
Bug Description
[Impact]
On some arm systems makedumpfile fails to translate virtual to physical addresses properly.
This may result in makedumpfile looping forever exhausting
all memory, or translating a virtual address to an invalid physical address
and then failing and falling back to cp.
The reason it cannot resolve some addresses is because the PMD mask is wrong.
When physical address mask allows up to 48bits pmd mask should allow the
same, currently pmd mask is set to 40bits (see commit [1]).
Commit [1] fixes this bug.
[Test Case]
To hit this bug you need a system that needs physical addresses over 1TB.
This may be either because you have a lot
of memory or because the firmware mapped some memory above 1TB for some
reason [1].
A user hit this bug because firmware mapped memory above 1TB and provided a
dump so I could reproduce the bug when running makedumpfile on the dump.
[Regression Potential]
This commit changes the PMD_SECTION_MASK for arm64. So any regression potential
would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation
from virtual to physical addresses and therefore any regression would happen during
this process.
[Other]
[1] https:/
When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows:
# echo 1> / proc / sys / kernel / sysrq
# echo c> / proc / sysrq-trigger
The logs are as follows:
kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/
kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0
kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8
kdump-tools[646]: vaddr_to_
kdump-tools[646]: readmem: Can't convert a virtual address(
kdump-tools[646]: readmem: type_addr: 0, addr:ffff9e653690, size:1032
kdump-tools[646]: validate_
kdump-tools[646]: get_mem_section: Could not validate mem_section.
kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section.
kdump-tools[646]: makedumpfile Failed.
kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp'
But when I use the HWE kernel, I find that there is no such problem.
The HEW kernel version: 5.3.0-42-generic
information type: | Public → Public Security |
Changed in linux (Ubuntu): | |
assignee: | nobody → Ioanna Alifieraki (joalif) |
Changed in linux (Ubuntu Bionic): | |
status: | New → Confirmed |
assignee: | nobody → Ioanna Alifieraki (joalif) |
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Bionic): | |
importance: | Undecided → Medium |
description: | updated |
tags: | added: sts-sponsor-mfo |
Changed in linux (Ubuntu Xenial): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Ioanna Alifieraki (joalif) |
Changed in linux (Ubuntu Bionic): | |
status: | Confirmed → In Progress |
Changed in linux (Ubuntu Eoan): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Ioanna Alifieraki (joalif) |
Changed in linux (Ubuntu Focal): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Ioanna Alifieraki (joalif) |
Changed in linux (Ubuntu Groovy): | |
status: | Confirmed → In Progress |
tags: | added: patch |
Changed in linux (Debian): | |
status: | Unknown → New |
tags: |
added: sts-sponsor-mfo-and-slashd removed: sts-sponsor-mfo |
Changed in makedumpfile (Ubuntu Groovy): | |
assignee: | nobody → Ioanna Alifieraki (joalif) |
importance: | Undecided → Medium |
status: | New → In Progress |
tags: |
added: sts-sponsor-mfo removed: sts-sponsor-mfo-and-slashd |
affects: | linux (Debian) → makedumpfile (Debian) |
no longer affects: | linux (Ubuntu) |
no longer affects: | linux (Ubuntu Xenial) |
no longer affects: | linux (Ubuntu Bionic) |
no longer affects: | linux (Ubuntu Eoan) |
no longer affects: | linux (Ubuntu Focal) |
no longer affects: | linux (Ubuntu Groovy) |
Changed in makedumpfile (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in makedumpfile (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in makedumpfile (Ubuntu Eoan): | |
importance: | Undecided → Medium |
Changed in makedumpfile (Ubuntu Focal): | |
importance: | Undecided → Medium |
tags: | removed: sts-sponsor-mfo |
Changed in makedumpfile (Debian): | |
status: | New → Fix Released |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1869465
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.