From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: Tao Liu <ltao@redhat.com>,
yamazaki-msmt@nec.com, k-hagio-ab@nec.com,
kexec@lists.infradead.org
Cc: aravinda@linux.vnet.ibm.com, Tao Liu <ltao@redhat.com>
Subject: Re: [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering
Date: Thu, 28 May 2026 11:37:48 -0700 [thread overview]
Message-ID: <87o6hzpegz.fsf@oracle.com> (raw)
In-Reply-To: <20260414102656.55200-1-ltao@redhat.com>
Tao Liu <ltao@redhat.com> writes:
> 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 EXTENSION=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.
> rhel8.x is not supported, 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
>
> v5 -> v4:
>
> 1) Add "make EXTENSION=on" switch to customize the extension feature.
> 2) Clean up macros within btf_info.h.
> 3) Updated doc and a sample extension to demo the extension usage.
> 4) Use MSG()/ERRMSG() rather than fprintf().
> 5) Add return value check for readmem().
> 6) Allow "makedumpfile -d 1 --extension ext.so" to enter extension.
> 7) The patches are organized as follows:
>
> --- <customization specific> ---
> 9. Add amdgpu mm pages filtering extension
>
> --- <code should be merged> ---
> 8. Doc: Add --extension option to makedumpfile manual
> 7. Add sample extension as an example reference
> 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 9 is customization specific, merging depends on the strategy of
> maintenance.
> Patch 1 ~ 8 are common code which should be merged with makedumpfile.
Hi Tao,
Just to be thorough, I did re-read the code of each patch, in addition
to reviewing the diff from v4 to v5.
I've also re-based my userspace stack extension on this new version.
I think it is ready to go.
Reviewed-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Thanks,
Stephen
> Link to v4: https://lore.kernel.org/kexec/20260317150743.69590-1-ltao@redhat.com/
> 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 (9):
> 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
> Add sample extension as an example reference
> Doc: Add --extension option to makedumpfile manual
> Add amdgpu mm pages filtering extension
>
> Makefile | 15 +-
> README | 6 +
> btf_info.c | 375 +++++++++++++++++++++++++
> btf_info.h | 77 ++++++
> extension.c | 338 ++++++++++++++++++++++
> extension.h | 16 ++
> extensions/Makefile | 13 +
> extensions/amdgpu_filter.c | 221 +++++++++++++++
> extensions/maple_tree.c | 328 ++++++++++++++++++++++
> extensions/maple_tree.h | 7 +
> extensions/sample.c | 69 +++++
> kallsyms.c | 554 +++++++++++++++++++++++++++++++++++++
> kallsyms.h | 87 ++++++
> makedumpfile.8.in | 11 +-
> makedumpfile.c | 44 ++-
> makedumpfile.h | 12 +
> makedumpfile.ld | 16 ++
> 17 files changed, 2180 insertions(+), 9 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 extensions/sample.c
> create mode 100644 kallsyms.c
> create mode 100644 kallsyms.h
> create mode 100644 makedumpfile.ld
>
> --
> 2.47.0
next prev parent reply other threads:[~2026-05-28 18:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 10:26 [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 1/9] Reserve sections for makedumpfile and extenions Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 2/9] Implement kernel kallsyms resolving Tao Liu
2026-06-15 8:09 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-15 23:04 ` Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 3/9] Implement kernel btf resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 4/9] Implement kernel module's kallsyms resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 5/9] Implement kernel module's btf resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 6/9] Add makedumpfile extensions support Tao Liu
2026-06-15 8:09 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-15 17:12 ` Stephen Brennan
2026-06-15 23:03 ` Tao Liu
2026-06-16 1:39 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-16 2:17 ` Tao Liu
2026-06-16 7:51 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-16 10:31 ` Tao Liu
2026-06-17 1:50 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-17 2:34 ` Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 7/9] Add sample extension as an example reference Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 8/9] Doc: Add --extension option to makedumpfile manual Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 9/9] Add amdgpu mm pages filtering extension Tao Liu
2026-05-20 4:55 ` [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering Tao Liu
2026-05-28 18:37 ` Stephen Brennan [this message]
2026-05-28 22:02 ` Tao Liu
2026-05-29 21:11 ` Krister Johansen
2026-06-01 23:12 ` Tao Liu
2026-06-02 0:47 ` Krister Johansen
2026-06-02 3:04 ` Tao Liu
2026-06-02 4:49 ` Krister Johansen
2026-06-11 1:24 ` Tao Liu
2026-06-10 23:42 ` [PATCH] Add erase_sample extension as an data erase reference Tao Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o6hzpegz.fsf@oracle.com \
--to=stephen.s.brennan@oracle.com \
--cc=aravinda@linux.vnet.ibm.com \
--cc=k-hagio-ab@nec.com \
--cc=kexec@lists.infradead.org \
--cc=ltao@redhat.com \
--cc=yamazaki-msmt@nec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox