makedumpfile (1:1.7.8-1)
[PTS] [DDPO]
UNREL: VCS matches the version in the archive, but the VCS changelog is UNRELEASED. The uploader should update the changelog and tag the release.
- Git: https://salsa.debian.org/debian/makedumpfile.git
-
- Branch: debian/latest
- Path: debian/changelog
- Repo size: 872448
- Browser: https://salsa.debian.org/debian/makedumpfile
- Last scan: 2026-10-03 21:38:02+00
- Next scan: 2026-10-11 10:05:00+00
- Debian changelog in Git:
makedumpfile (1:1.7.8-1) UNRELEASED; urgency=medium
* New upstream release.
-- dann frazier <dannf@debian.org> Mon, 28 Sep 2026 11:41:56 -0600
- This branch is 10 commits ahead of tag debian/1%1.7.7-1
- Git log:
commit 1df6b20944fb91d714a877dbf4c989d4674ac804
Author: dann frazier <dannf@debian.org>
Date: Mon Sep 28 11:42:13 2026 -0600
New upstream release.
commit ca661c206bf7aa17f0d830130c05fbf513189e5f
Merge: b5d3624 fd3cbe1
Author: dann frazier <dannf@debian.org>
Date: Mon Sep 28 11:41:36 2026 -0600
Update upstream source from tag 'upstream/1.7.8'
Update to upstream version '1.7.8'
with Debian dir 7ca2b9c7ab679515c4f7f994e03c9731df0be80a
commit fd3cbe1db67342f6a7a7f7490f4e37f7ac70f9ec
Merge: e4ae6b5 65e0b54
Author: dann frazier <dannf@debian.org>
Date: Mon Sep 28 11:41:36 2026 -0600
New upstream version 1.7.8
commit b5d3624f7971f235156f4dd6a0a555f327f6e1d3
Author: dann frazier <dannf@debian.org>
Date: Mon Sep 28 11:33:46 2026 -0600
Stop using git-debrebase
It's always a struggle to update this package because it's the only one
I maintain that uses git-debrebase. Restructure the branch to be more
gbp-like.
Signed-off-by: dann frazier <dannf@debian.org>
commit 65e0b5488ffe840035c6e165a5149dc5da769d97
Author: YAMAZAKI Masamitsu <yamazaki-msmt@nec.com>
Date: Thu Oct 30 14:32:29 2025 +0900
[v1.7.8] Update version
Update makedumpfile to version 1.7.8.
This version supports the following new kernels:
- 6.15, 6.16, 6.17 (x86_64)
Signed-off-by: YAMAZAKI Masamitsu <yamazaki-msmt@nec.com>
commit a443eb654bc91858d22ccdf5d68a090df94f9423
Author: Tao Liu <ltao@redhat.com>
Date: Tue Oct 21 11:24:00 2025 +1300
[PATCH v2] dwarf_info: Fix an infinite recursion bug for Rust symbols
There is an infinite recursion bug noticed in eppic function with Rust
symbols. The root case is still unknown.
$ makedumpfile -l -d 31 --eppic test.c -x vmlinux vmcore dump.ld31
Segmentation fault (core dumped)
Avoid the bug by skip the Rust CompileUnits for now, since currently we
don't need to deal with Rust symbols.
Suggested-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
[ kh: added note to man page and editted commit log ]
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
commit f1f3561cdbdf3f5e626b6e15e3899f80b6d1a975
Author: Tao Liu <ltao@redhat.com>
Date: Tue Oct 21 11:23:59 2025 +1300
[PATCH] dwarf_info: Make get_symbol_addr_all() support kernel address randomization
Without the patch, eppic scripts cannot get symbol addresses in a vmcore
captured on a KASLR-enabled kernel.
$ makedumpfile -l -d 31 --eppic test.c -x vmlinux vmcore dump.ld31
...
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(ffffffff81e00100) to physical address.
readmem: type_addr: 0, addr:ffffffff81e00100, size:1
Signed-off-by: Tao Liu <ltao@redhat.com>
[ kh: editted commit log ]
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
commit 65bf4c9ef0fd0cbf2fb99b60e15b00d984b391b8
Author: Tao Liu <ltao@redhat.com>
Date: Wed Jun 25 14:23:44 2025 +1200
[PATCH v2] Fix a data race in multi-threading mode (--num-threads=N)
A vmcore corrupt issue has been noticed in powerpc arch [1]. It can be
reproduced with upstream makedumpfile.
When analyzing the corrupt vmcore using crash, the following error
message will output:
crash: compressed kdump: uncompress failed: 0
crash: read error: kernel virtual address: c0001e2d2fe48000 type:
"hardirq thread_union"
crash: cannot read hardirq_ctx[930] at c0001e2d2fe48000
crash: compressed kdump: uncompress failed: 0
If the vmcore is generated without num-threads option, then no such
errors are noticed.
With --num-threads=N enabled, there will be N sub-threads created. All
sub-threads are producers which responsible for mm page processing, e.g.
compression. The main thread is the consumer which responsible for
writing the compressed data into file. page_flag_buf->ready is used to
sync main and sub-threads. When a sub-thread finishes page processing,
it will set ready flag to be FLAG_READY. In the meantime, main thread
looply check all threads of the ready flags, and break the loop when
find FLAG_READY.
page_flag_buf->ready is read/write by main/sub-threads simultaneously,
but it is unprotected and unsafe. I have tested both mutex and atomic_rw
can fix this issue. This patch takes atomic_rw for its simplicity.
[1]: https://github.com/makedumpfile/makedumpfile/issues/15
Resolves: https://github.com/makedumpfile/makedumpfile/issues/15
Tested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
commit c1a930185482a72b290099a4f814c5f32b6e4cc8
Author: Zhiquan Li <zhiquan1.li@intel.com>
Date: Mon Jun 9 13:02:44 2025 +0800
[PATCH] Add confidential VM unaccepted free pages support on Linux 6.16 and later
UEFI Specification version 2.9 introduces the concept of memory
acceptance: some Virtual Machine platforms, such as Intel TDX or AMD
SEV-SNP, requiring memory to be accepted before it can be used by the
guest. Accepting happens via a protocol specific for the Virtual
Machine platform[1].
Before unaccepted memory is accepted by guest, any access from guest
will result in the guest failed, as well as the kexec'ed kernel. So,
the kexec'ed kernel will skip these pages and fill in zero data for the
reader of vmcore.
However, it introduces a problem. When exclude a page filled with zero,
a pd_zero, which sizeof(page_desc_t) is 24 bytes, will be written into
cd_header and this part is not compressed by design. As the unaccepted
pages are exported as zero pages, which means ~1/170 of the capacity of
unaccepted memory will be added into vmcore additionally. In fact, they
should be considered as free pages and most of the time should be
excluded.
Unaccepted memory is unusable free memory, so they are not managed by
buddy, instead, they are added to a new list zone.unaccepted_pages only
when the order is MAX_PAGE_ORDER each time conventionally. The new
page type, PGTY_unaccepted can be used to identify whether a page is
unaccepted[2]. Therefore, add following changes to exclude them like
free pages:
1. Add NUMBER(PAGE_UNACCEPTED_MAPCOUNT_VALUE) to identify a page is
unaccepted, a kernel patch[3] to export the value of page type
PAGE_UNACCEPTED_MAPCOUNT_VALUE since kernel 6.16.
2. Add a condition to exclude these unaccepted free pages.
Dumping host kernel will not be impacted by the modification, because it
cannot enable CONFIG_UNACCEPTED_MEMORY, so the page type
PAGE_UNACCEPTED_MAPCOUNT_VALUE cannot be found in vmcoreinfo and skip
the step.
Here is a vmcore size statistic of a freshly booted TD VM with different
memory sizes:
VM.mem | Before After
-------+----------------
512G | ~4.9G ~2.0G
256G | ~2.0G ~1.1G
[1] https://lore.kernel.org/all/20230606142637.5171-1-kirill.shutemov@linux.intel.com/
[2] https://lore.kernel.org/all/20240809114854.3745464-5-kirill.shutemov@linux.intel.com/
[3] https://lore.kernel.org/all/20250405060610.860465-1-zhiquan1.li@intel.com/
Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com>
commit b86575bbced697445bdc7f739c1456f84e44c401
Author: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Wed Jul 2 08:37:26 2025 +0900
[PATCH] Mark start of 1.7.8 development phase with version 1.7.7++
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
