On 2026/01/20 11:54, 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 > Loaded extension: ./extensions/amdgpu_filter.so > makedumpfile Completed. > User time (seconds): 6.37 > System time (seconds): 0.70 > Elapsed (wall clock) time (h:mm:ss or m:ss): 0:07.10 > Maximum resident set size (kbytes): 38024 > ... > > 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/[email protected]/ > [3]: https://people.redhat.com/~ltao/core/vmcore > [4]: https://gist.github.com/liutgnu/a8cbce1c666452f1530e1410d1f352df > > v3 -> v2: > > 1) Removed btf/kallsyms support for eppic script, and introduced > makedumpfile .so extension instead. The reason of removing eppic > support is: > a) Native binary code as .so has better performance than scripting, > see the time consumption contrast above. > b) Eppic library has memory leaks which hasn't been fixed totally, > memeory leaks in 2nd kernel might be fatal. > > 2) Removed the code of manually parsing btf info, and used libbpf for > btf info parsing instead. The reason of removing manually parsing is: > a) Less code modification to makedumpfile, easier to maintain. > b) The performance of using libbpf is as good as manual parsing + > hash table indexing, as well as less memory consumption, see time > and memory consumption contrast above. > > 3) The patches are organized as follows: > > --- <only for test purpose, don't merge> --- > 8.Filter amdgpu mm pages > 7.Add maple tree support to makedumpfile extension > > --- <code should be merged> --- > 6.Add page filtering function > 5.Add makedumpfile extension support > 4.Implement kernel modules' btf resolving > 3.Implement kernel modules' kallsyms resolving > 2.Implement kernel btf resolving > 1.Implement kernel kallsyms resolving > > Patch 7 & 8 are customization specific, which can be maintained > separately. > Patch 1 ~ 6 are common code which should be integrate with makedumpfile. > > Link to v2: > https://lore.kernel.org/kexec/[email protected]/ > Link to v1: > https://lore.kernel.org/kexec/[email protected]/ > > Tao Liu (8): > Implement kernel kallsyms resolving > Implement kernel btf resolving > Implement kernel modules' kallsyms resolving > Implement kernel modules' btf resolving > Add makedumpfile extension support > Add page filtering function > Add maple tree support to makedumpfile extension > Filter amdgpu mm pages > > Makefile | 9 +- > btf_info.c | 260 +++++++++++++++++++++++++ > btf_info.h | 66 +++++++ > erase_info.c | 98 ++++++++++ > erase_info.h | 12 ++ > extension.c | 82 ++++++++ > extensions/Makefile | 10 + > extensions/amdgpu_filter.c | 90 +++++++++ > extensions/maple_tree.c | 336 +++++++++++++++++++++++++++++++++ > extensions/maple_tree.h | 6 + > kallsyms.c | 376 +++++++++++++++++++++++++++++++++++++ > kallsyms.h | 20 ++ > makedumpfile.c | 35 +++- > makedumpfile.h | 11 ++ > 14 files changed, 1405 insertions(+), 6 deletions(-) > create mode 100644 btf_info.c > create mode 100644 btf_info.h > create mode 100644 extension.c > 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
Thank you for your the v3 patch. And thanks for the appropriate improvements. I believe the results will be significantly improved by stopping use of eppic and using libbpf instead. My concerns are as follows: * Performance has improved compared to the version using eppic, but I would like to see a comparison of performance without these patches applied. * This mechanism is enabled when .so (shared libraries) are present, but I think it would be better to have an option to turn this feature on or off. If you don't use shared libraries, you have to delete or move them, which can be inconvenient. I'm looking forward to v4, which will improve things like calculation Order. Masa
