[PATCH v4][makedumpfile 0/7] btf/kallsyms based makedumpfile extension for mm page filtering
Tao Liu
ltao at redhat.com
Tue Apr 14 03:37:18 PDT 2026
Hi Kazu,
Thanks a lot for your review, and sorry for the late reply.
On Fri, Apr 3, 2026 at 9:07 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at nec.com> wrote:
>
> On 2026/03/18 0:07, Tao Liu wrote:
> > A) This patchset will introduce the following features to makedumpfile:
> >
> > 1) Add .so extension support to makedumpfile
> > 2) Enable btf and kallsyms for symbol type and address resolving.
> >
> > B) The purpose of the features are:
> >
> > 1) Currently makedumpfile filters mm pages based on page flags, because flags
> > can help to determine one page's usage. But this page-flag-checking method
> > lacks of flexibility in certain cases, e.g. if we want to filter those mm
> > pages occupied by GPU during vmcore dumping due to:
> >
> > a) GPU may be taking a large memory and contains sensitive data;
> > b) GPU mm pages have no relations to kernel crash and useless for vmcore
> > analysis.
> >
> > But there is no GPU mm page specific flags, and apparently we don't need
> > to create one just for kdump use. A programmable filtering tool is more
> > suitable for such cases. In addition, different GPU vendors may use
> > different ways for mm pages allocating, programmable filtering is better
> > than hard coding these GPU specific logics into makedumpfile in this case.
> >
> > 2) Currently makedumpfile already contains a programmable filtering tool, aka
> > eppic script, which allows user to write customized code for data erasing.
> > However it has the following drawbacks:
> >
> > a) cannot do mm page filtering.
> > b) need to access to debuginfo of both kernel and modules, which is not
> > applicable in the 2nd kernel.
> > c) eppic library has memory leaks which are not all resolved [1]. This
> > is not acceptable in 2nd kernel.
> >
> > makedumpfile need to resolve the dwarf data from debuginfo, to get symbols
> > types and addresses. In recent kernel there are dwarf alternatives such
> > as btf/kallsyms which can be used for this purpose. And btf/kallsyms info
> > are already packed within vmcore, so we can use it directly.
> >
> > With these, this patchset introduces makedumpfile extensions, which is based
> > on btf/kallsyms symbol resolving, and is programmable for mm page filtering.
> > The following section shows its usage and performance, please note the tests
> > are performed in 1st kernel.
> >
> > 3) Compile and run makedumpfile extensions:
> >
> > $ make LINKTYPE=dynamic USELZO=on USESNAPPY=on USEZSTD=on
> > $ make extensions
> >
> > $ /usr/bin/time -v ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
> > /tmp/extension.out --extension amdgpu_filter.so
> > Loaded extension: ./extensions/amdgpu_filter.so
> > makedumpfile Completed.
> > User time (seconds): 5.08
> > System time (seconds): 0.84
> > Percent of CPU this job got: 99%
> > Elapsed (wall clock) time (h:mm:ss or m:ss): 0:05.95
> > Maximum resident set size (kbytes): 17360
> > ...
> >
> > To contrast with eppic script of v2 [2]:
> >
> > $ /usr/bin/time -v ./makedumpfile -d 31 -l /var/crash/127.0.0.1-2025-06-10-18\:03\:12/vmcore
> > /tmp/eppic.out --eppic eppic_scripts/filter_amdgpu_mm_pages.c
> > makedumpfile Completed.
> > User time (seconds): 8.23
> > System time (seconds): 0.88
> > Elapsed (wall clock) time (h:mm:ss or m:ss): 0:09.16
> > Maximum resident set size (kbytes): 57128
> > ...
> >
> > -rw------- 1 root root 367475074 Jan 19 19:01 /tmp/extension.out
> > -rw------- 1 root root 367475074 Jan 19 19:48 /tmp/eppic.out
> > -rw------- 1 root root 387181418 Jun 10 18:03 /var/crash/127.0.0.1-2025-06-10-18:03:12/vmcore
> >
> > C) Discussion:
> >
> > 1) GPU types: Currently only tested with amdgpu's mm page filtering, others
> > are not tested.
> > 2) OS: The code can work on rhel-10+/rhel9.5+ on x86_64/arm64/s390/ppc64.
> > Others are not tested.
> >
> > D) Testing:
> >
> > If you don't want to create your vmcore, you can find a vmcore which I
> > created with amdgpu mm pages unfiltered [3], the amdgpu mm pages are
> > allocated by program [4]. You can use the vmcore in 1st kernel to filter
> > the amdgpu mm pages by the previous performance testing cmdline. To
> > verify the pages are filtered in crash:
> >
> > Unfiltered:
> > crash> search -c "!QAZXSW@#EDC"
> > ffff96b7fa800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > ffff96b87c800000: !QAZXSW@#EDCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> > crash> rd ffff96b7fa800000
> > ffff96b7fa800000: 405753585a415121 !QAZXSW@
> > crash> rd ffff96b87c800000
> > ffff96b87c800000: 405753585a415121 !QAZXSW@
> >
> > Filtered:
> > crash> search -c "!QAZXSW@#EDC"
> > crash> rd ffff96b7fa800000
> > rd: page excluded: kernel virtual address: ffff96b7fa800000 type: "64-bit KVADDR"
> > crash> rd ffff96b87c800000
> > rd: page excluded: kernel virtual address: ffff96b87c800000 type: "64-bit KVADDR"
> >
> > [1]: https://github.com/lucchouina/eppic/pull/32
> > [2]: https://lore.kernel.org/kexec/20251020222410.8235-1-ltao@redhat.com/
> > [3]: https://people.redhat.com/~ltao/core/vmcore
> > [4]: https://gist.github.com/liutgnu/a8cbce1c666452f1530e1410d1f352df
> >
> > v4 -> v3:
> >
> > 1) Get rid of all hash table usage. So only required syms/types info
> > will be stored, rather than install all kernel's syms/types. To do this,
> > special elf sections as .init_ksyms/ktypes are used for the required info
> > declaration/storage.
> >
> > 2) Support extension callback for makedumpfile, so during mm page
> > filtering, extension can help to decide if keep/discard the page.
> >
> > 3) The patches are organized as follows:
> >
> > --- <only for test purpose, don't merge> ---
> > 7. Filter amdgpu mm pages
> >
> > --- <code should be merged> ---
> > 6. Add makedumpfile extensions support
> > 5. Implement kernel module's btf resolving
> > 4. Implement kernel module's kallsyms resolving
> > 3. Implement kernel btf resolving
> > 2. Implement kernel kallsyms resolving
> > 1. Reserve sections for makedumpfile and extenions
> >
> > Patch 7 is customization specific, which can be maintained separately.
> > Patch 1 ~ 6 are common code which should be integrate with makedumpfile.
>
> Hi Tao,
>
> thank you for the update, nice and interesting implementation :-)
>
> Here is my comments to the whole patchset:
>
> - I think we need a documentation about this function and it's better to
> have a simple example extension (that does not need to be updated) if
> possible.
Please check the v5 that I just posted upstream. I have updated the
doc, as well as a sample extension for code reference.
>
> - It could not be built on RHEL8 and it's ok if libbpf is too old, but
> which version of libbpf is required? It should be written in a
> documentation.
Yes, updated the version info of libbpf in v5. In addition, I have
tested the rhel8 kernel won't not work for makedumpfile extension. It
is because the vmcoreinfo lacks kallsyms info, which kernel patch is
not backported to rhel8. A rhel-10+/rhel9.5+ or fedora 41+ can do.
>
> - Looking at this, e.g. "makedumpfile -d 1 --extension foo.so" does not
> run run_extension_callback(), is it intended?
It is a bug, fixed in v5, thanks for pointing it out.
>
> /*
> * Exclude cache pages, cache private pages, user data pages,
> * and hwpoison pages.
> */
> if (info->dump_level & DL_EXCLUDE_CACHE ||
> info->dump_level & DL_EXCLUDE_CACHE_PRI ||
> info->dump_level & DL_EXCLUDE_USER_DATA ||
> NUMBER(PG_hwpoison) != NOT_FOUND_NUMBER ||
> ((info->dump_level & DL_EXCLUDE_FREE) &&
> info->page_is_buddy)) {
> if (!exclude_unnecessary_pages(cycle)) {
> ERRMSG("Can't exclude unnecessary pages.\n");
> return FALSE;
> }
> }
>
> - I'm concerned that readmem()s don't have check on return value, it's
> better to be able to determine which value is unable to be read.
All checked in v5.
>
> The other comments are in each patch.
>
> Thanks,
> Kazu
>
> >
> > Link to v3: https://lore.kernel.org/kexec/20260120025500.25095-1-ltao@redhat.com/
> > Link to v2: https://lore.kernel.org/kexec/20251020222410.8235-1-ltao@redhat.com/
> > Link to v1: https://lore.kernel.org/kexec/20250610095743.18073-1-ltao@redhat.com/
> >
> > Tao Liu (7):
> > Reserve sections for makedumpfile and extenions
> > Implement kernel kallsyms resolving
> > Implement kernel btf resolving
> > Implement kernel module's kallsyms resolving
> > Implement kernel module's btf resolving
> > Add makedumpfile extensions support
> > Filter amdgpu mm pages
> >
> > Makefile | 11 +-
> > btf_info.c | 345 +++++++++++++++++++++++++++
> > btf_info.h | 92 ++++++++
> > extension.c | 300 +++++++++++++++++++++++
> > extension.h | 12 +
> > extensions/Makefile | 12 +
> > extensions/amdgpu_filter.c | 190 +++++++++++++++
> > extensions/maple_tree.c | 307 ++++++++++++++++++++++++
> > extensions/maple_tree.h | 6 +
> > kallsyms.c | 473 +++++++++++++++++++++++++++++++++++++
> > kallsyms.h | 94 ++++++++
> > makedumpfile.c | 41 +++-
> > makedumpfile.h | 13 +
> > makedumpfile.ld | 15 ++
> > 14 files changed, 1903 insertions(+), 8 deletions(-)
> > create mode 100644 btf_info.c
> > create mode 100644 btf_info.h
> > create mode 100644 extension.c
> > create mode 100644 extension.h
> > create mode 100644 extensions/Makefile
> > create mode 100644 extensions/amdgpu_filter.c
> > create mode 100644 extensions/maple_tree.c
> > create mode 100644 extensions/maple_tree.h
> > create mode 100644 kallsyms.c
> > create mode 100644 kallsyms.h
> > create mode 100644 makedumpfile.ld
> >
More information about the kexec
mailing list