We still need to discuss the feasibility/need of inclusion of each fix
in Xenial.
** Description changed:
- Due to an issue in the kaslr address resolution in makedumpfile, we may
- get the following error when collecting a dump:
+ [Impact]
+
+ * Currently makedumpfile has 2 flaws due to: (a) out of synchronization
+ with kernel code and, (b) kaslr handling. The first is related to a
+ definition of a memory flag bit, whereas the second is about kaslr
+ offset calculation - both cause similar failures when collecting the
+ vmcore in kdump environment:
Excluding unnecessary pages : [ 46.3 %] / __vtop4_x86_64[ 39.341233]: Can't
get a valid pmd_pte.
readmem: Can't convert a virtual address(ffffe05cb4000000) to physical
address.
readmem: type_addr: 0, addr:ffffe05cb4000000, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
- This is believed to be fixed by commit: 3222d4ad04c6 ("x86_64: fix
- get_kaslr_offset_x86_64() to return kaslr_offset correctly"). This LP
- keeps track of Test/SRU for this commit.
+ * The report is mainly related to the first issue, which started to
+ happen after the merge of kernel commit 326e1b8f83a4 ("mm/sparsemem:
+ introduce a SECTION_IS_EARLY flag"), introduced in kernel 5.3. After
+ this commit, a memory flag was changed and induced the error in dump
+ collection. The fix is available in makedumpfile, as commit 7bdb468c2c
+ ("Increase SECTION_MAP_LAST_BIT to 4"). This is hereby SRUed to Bionic
+ (due to HWE kernel 5.3), Eoan and Focal.
+
+ * The other issue is fixed in both Eoan and Focal, on makedumpfile
+ 1.6.6-based version. It is related with the kaslr offset: if the offset
+ is small enough, we may return 0 wrongly in get_kaslr_offset_x86_64(),
+ causing the vmcore collection to fail or even worse, to erase unintended
+ data from the memory dump. This is fixed by makedumpfile commit
+ 3222d4ad04 ("x86_64: fix get_kaslr_offset_x86_64() to return
+ kaslr_offset correctly"), which isn't present in versions before 1.6.6.
+ We hereby SRU this fix for Bionic.
+
+ * Notice this modification is being worked concurrently with other
+ kdump-tools' changes in LP #1828596.
+
+ [Test Case]
+
+ 1) Deploy an Eoan VM e.g. with uvt-kvm;
+ 2) Set-up console output in the guest;
+ 3) Install the kdump-tools package;
+ 4) Configure and collect a dump (with sysrq to panic the system) - the error
aforementioned is observed given Eoan kernel is 5.3-based.
+
+ [Regression Potential]
+
+ * The modifications hereby proposed are minimal and scope-constrained to
+ makedumpfile in x86_64; both are merged in makedumpfile upstream, one of
+ them being already released in E/F. An unlikely regression would
+ potentially fails vmcore collection in kdump environment.
** Changed in: makedumpfile (Ubuntu Xenial)
Status: Invalid => Opinion
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1857616
Title:
Cannot collect dump due to "Can't get a valid pmd_pte" error
Status in makedumpfile package in Ubuntu:
Confirmed
Status in makedumpfile source package in Xenial:
Opinion
Status in makedumpfile source package in Bionic:
Confirmed
Status in makedumpfile source package in Disco:
Invalid
Status in makedumpfile source package in Eoan:
Confirmed
Status in makedumpfile source package in Focal:
Confirmed
Bug description:
[Impact]
* Currently makedumpfile has 2 flaws due to: (a) out of
synchronization with kernel code and, (b) kaslr handling. The first is
related to a definition of a memory flag bit, whereas the second is
about kaslr offset calculation - both cause similar failures when
collecting the vmcore in kdump environment:
Excluding unnecessary pages : [ 46.3 %] / __vtop4_x86_64[ 39.341233]: Can't
get a valid pmd_pte.
readmem: Can't convert a virtual address(ffffe05cb4000000) to physical
address.
readmem: type_addr: 0, addr:ffffe05cb4000000, size:32768
__exclude_unnecessary_pages: Can't read the buffer of struct page.
create_2nd_bitmap: Can't exclude unnecessary pages.
* The report is mainly related to the first issue, which started to
happen after the merge of kernel commit 326e1b8f83a4 ("mm/sparsemem:
introduce a SECTION_IS_EARLY flag"), introduced in kernel 5.3. After
this commit, a memory flag was changed and induced the error in dump
collection. The fix is available in makedumpfile, as commit 7bdb468c2c
("Increase SECTION_MAP_LAST_BIT to 4"). This is hereby SRUed to Bionic
(due to HWE kernel 5.3), Eoan and Focal.
* The other issue is fixed in both Eoan and Focal, on makedumpfile
1.6.6-based version. It is related with the kaslr offset: if the
offset is small enough, we may return 0 wrongly in
get_kaslr_offset_x86_64(), causing the vmcore collection to fail or
even worse, to erase unintended data from the memory dump. This is
fixed by makedumpfile commit 3222d4ad04 ("x86_64: fix
get_kaslr_offset_x86_64() to return kaslr_offset correctly"), which
isn't present in versions before 1.6.6. We hereby SRU this fix for
Bionic.
* Notice this modification is being worked concurrently with other
kdump-tools' changes in LP #1828596.
[Test Case]
1) Deploy an Eoan VM e.g. with uvt-kvm;
2) Set-up console output in the guest;
3) Install the kdump-tools package;
4) Configure and collect a dump (with sysrq to panic the system) - the error
aforementioned is observed given Eoan kernel is 5.3-based.
[Regression Potential]
* The modifications hereby proposed are minimal and scope-constrained
to makedumpfile in x86_64; both are merged in makedumpfile upstream,
one of them being already released in E/F. An unlikely regression
would potentially fails vmcore collection in kdump environment.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1857616/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
