Re: [PATCH makedumpfile 0/9] Improvements to makedumpfile extensions, plus userspace stack tracing extension

Hi Tao & Kazu (responding to both in one message for simplicity :)

Tao Liu <[email protected]> writes:
> Hi Kazu,
>
> On Fri, Aug 7, 2026 at 1:52 PM HAGIO KAZUHITO(萩尾　一仁) <[email protected]> wrote:
>>
>> On 2026/07/14 9:45, Stephen Brennan wrote:
>> > Hello all,
>> >
>> > Building on Tao Liu's excellent work for makedumpfile extensions, I'd like to
>> > share some incremental improvements to the extension system, as well as my own
>> > two extensions which enable userspace stack tracing. There are three topics
>> > related to the core makedumpfile extension system which are addressed here:
>> >
>> > 1. Tail pages handling. As patch 1 explains, extensions currently get called for
>> > tail pages, but their decisions are not respected. I believe the best approach
>> > is to only call extensions for the head page, but allow extensions to return a
>> > decision related to just a subset of the pages. To this end, patch 7 adds
>> > PG_INCLUDE_HEAD to include just the head page (leaving the rest up to the
>> > default policy), and patch 9 shows the elfheader extension which uses that
>> > functionality.
>> >
>> > 2. Counting pages included by extensions. This is done by patch 4. It alters the
>> > logic because it's really helpful to know whether a page would have been
>> > included by makedumpfile's dump-level filtering anyway, so we only count the
>> > additional pages.
>> >
>> > 3. Sharing makedumpfile's logic and knowledge about page metadata. Currently,
>> > extensions just get a "pcache" pointer, which means they must redo whatever
>> > logic makedumpfile has already done, in order to get information like
>> > compound_order. Patches 3, 5, and 6 factor out the page metadata into a new
>> > struct pginfo, which gets passed to extensions, and it also makes more of the
>> > helpers like "isSlab()" usable with this pointer.
>> >
>> > With those improvements, the final two patches (8 & 9) implement a pair of
>> > extensions that are useful for including a minimal amount of information which
>> > can be used to do stack traces of the userspace processes in a vmcore. The
>> > "userstack" extension includes the stack memory itself for each thread, and the
>> > "elfheader" extension includes the first page of mapped ELF files, so that ELF
>> > build IDs can be identified from the vmcore.
>> >
>> > My testing so far:
>> > - Live testing (/proc/kcore) x86_64 on Oracle UEK 8 (6.12.x based)
>> > - Refiltering on vmcores generated from UEK8, 7 (5.15.x based), 6 (5.4.x based)
>> > - Using the resulting filtered vmcores with drgn's contrib/pstack.py to generate
>> >    userspace stack traces.
>> >
>> > I still have significantly more testing to do and then share out:
>> > - Testing in kexec environment
>> > - Testing with upstream kernels, also verifying in a Fedora userspace
>> > - Sharing runtime and size comparisons with different workloads
>> >
>> > Despite the limited testing, I wanted to share these patches as they are,
>> > because I think the improvements for the core extensions framework are useful
>> > already, and don't require as much verification.
>> >
>> > For the extensions themselves, I would like to consider merging them as well, if
>> > there is interest. I think it would be useful for makedumpfile to contain shared
>> > extensions, including those for the GPU buffers which Tao Liu was working on, as
>> > well as the userspace stack tracing ones which I'm sharing.
>>
>> Hi Stephen, (and Tao)
>>
>> sorry for my slow review and thank you for your nice improvements!
>> I've reviewed the patches 1 to 7, these make good sense and look very
>> clean to me.

Thank you very much for reviewing.

>> few comments:
>> * I also think that including extensions is very useful, but for now,
>> I have to not increase the maintenance cost as far as possible, so
>> will not include them.  (this way has some good points, for example
>> you can update them freely without my slow review :-)

I understand: more code means more maintenance. We can maintain our
extensions separately, thanks for the clarity!

>> For user access, I'm thinking about adding makedumpfile extension list
>> to its wiki page [1].  If you agree on this, please provide their
>> information (extension name, author, link, description).

Here are mine:

- Extension Name: elfheader
  Author: Stephen Brennan (my email)
  Link: TBD - see below
  Description: Includes the first page of any ELF file in the page cache
  which is mapped to userspace. This inspired by bit 4 of
  coredump_filter (see core(5)) for userspace core dumps. By including
  the header of an ELF file, it's likely that a debugger can identify
  its build ID and use that to find debugging information for it. This
  helps when used in combination with the userstack extension.
- Extension Name: userstack
  Author: Stephen Brennan (my email)
  Link: TBD - see below
  Description: Attempts to include the memory pages for each userspace
  thread's stack. This can make it possible to unwind userspace process
  stacks using a vmcore, for example with drgn's contrib/pstack.py
  script.

>> * Could you add a description why PG_INCLUDE_HEAD is needed to the
>> patch 7, as we cannot add the cover letter and the patch 9.
>> (Text alone is ok, or you can use v2 just for the patch 7.)

Done as a text reply to patch 7.

>> Otherwise, there are typos and comment style gaps, but those can
>> be fixed when merging.

If it's not too much work, please do make those changes when merging.
Thank you!

>> and Tao, please check if your extension can be rebased on this
>> patchset.  and also if you agree the extension list, please provide
>> the information.
>
> Sure, I will check for the rebase. In the meantime, will the
> extensions to be maintained in one repo (e.g. makedumpfile extensions
> repo, so everyone can PR to it), or they are maintained in each of
> individual repos, and link them under
> https://github.com/makedumpfile/makedumpfile/wiki#extensions?

I am open to either. I would be willing to co-maintain an extensions
repository with Tao, for example at github.com/makedumpfile/extensions,
so that there is a common place to contribute. That is, if this
arrangement would work for all?

If we did create a common repository, I think we'd want to set up some
expectations on the quality & maintenance. EG, some may be marked as
"maintained" with a maintainer and a scope of maintenance (supported
kernel versions, supported architectures, etc), and others as
"unmaintained", where we just make sure that they build & run with
makedumpfile, but don't validate their behavior on specific kernels or
architectures.

On the other hand, if it's preferable to stay separate, then I'm happy
to find another place to maintain the userstack & elfheader extensions.

Thank you both!
Stephen

> Thanks,
> Tao Liu
>
>>
>> [1] https://github.com/makedumpfile/makedumpfile/wiki#extensions
>>
>> Thanks,
>> Kazu
>>
>> >
>> > Thanks,
>> > Stephen
>> >
>> > Stephen Brennan (9):
>> >    Do not call extensions for tail pages
>> >    Honor CFLAGS in extension/Makefile
>> >    Share page information with extension callbacks
>> >    Introduce a stat for pages retained by extension
>> >    Move page checks into makedumpfile.h
>> >    Simplify arguments for page checks
>> >    Add PG_INCLUDE_HEAD extension return status
>> >    Add userstack extension
>> >    Add elfheader extension
>> >
>> >   extension.c             |  10 +-
>> >   extension.h             |  10 +-
>> >   extensions/Makefile     |   8 +-
>> >   extensions/elfheader.c  |  93 ++++++++++++
>> >   extensions/userstack.c  | 325 ++++++++++++++++++++++++++++++++++++++++
>> >   extensions/vma_mtree.c  | 140 +++++++++++++++++
>> >   extensions/vma_mtree.h  |   7 +
>> >   extensions/vma_rbtree.c |  56 +++++++
>> >   extensions/vma_rbtree.h |  12 ++
>> >   makedumpfile.c          | 188 +++++++++--------------
>> >   makedumpfile.h          |  78 +++++++++-
>> >   11 files changed, 798 insertions(+), 129 deletions(-)
>> >   create mode 100644 extensions/elfheader.c
>> >   create mode 100644 extensions/userstack.c
>> >   create mode 100644 extensions/vma_mtree.c
>> >   create mode 100644 extensions/vma_mtree.h
>> >   create mode 100644 extensions/vma_rbtree.c
>> >   create mode 100644 extensions/vma_rbtree.h
>> >