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

[Tao Liu]

Hi Kazu & Stephen,

On Sat, Aug 8, 2026 at 4:45 PM HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab at nec.com> wrote:
>
> Hi Stephen, Tao,
>
> On 2026/08/08 6:24, Stephen Brennan wrote:
>
> >>> 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.
>
> Thanks, I copied this to see how it looks.
> https://github.com/makedumpfile/makedumpfile/wiki#extensions
>
> Please let me know if there are any points of concern.
>
> >>> * 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.
>
> Thanks, will use that.
>
> >>> 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.

I have checked my extension to rebase on this patchset. The result is:

1) Rebase fails, but only due to conflicts within extensions/Makefile.
These are small issues which would be very easy to fix.
2) Once 1 is fixed, after compile, my extension can work as expected.
However this is a coincidence.  Because my extension takes callback
as:

int extension_callback(unsigned long pfn, const void *pcache)
{
        struct ft_page_info *cur = NULL;
        return filter_page(pfn, &cur);
}

But this patchset changed the callback into:
run_extension_callback(unsigned long pfn, const void *pcache, const
struct pginfo *i)

My extension works because it only takes pfn as parameter, and the
handle_cbs[i]->cb() doesn't check function parameters. However, I
don't think it is a major issue, once the modification on extension.c
merged upstream, I can adjust the function signature of mine
accordingly.

> >>
> >> 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.
>
> I was thinking of separate repositories.  A single repository would be
> fine, but for now I have no plans to create one within the makedumpfile
> organization.
>
> (Looking back at crash extensions, some become obsolete quickly or
> have very specific functionality, making it difficult for anyone
> other than the original author to maintain.  For this reason, I think
> it is best for the authors themselves to manage them.)

Understood, extensions are designed to address one specific issue, and
is easy to get outdated when makedumpfile/crash utility keeping
following up the latest kernel, but extensions are often left behind
due to low usage. Let's go with maintainling the extensions by each
authors seperately and link them into
https://github.com/makedumpfile/makedumpfile/wiki#extensions

Thanks,
Tao Liu
>
> Thanks,
> Kazu