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

[Tao Liu]

Hi Kazu,

On Wed, Aug 12, 2026 at 1:32 PM HAGIO KAZUHITO(萩尾　一仁)
<k-hagio-ab at nec.com> wrote:
>
> Hi Tao,
>
> On 2026/08/11 15:11, Tao Liu wrote:
>
> >>>>> 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.
>
> Thank you for checking.  My main concern was the change in behavior,
> particularly with compound pages.  If your extension works well after
> some adjustments, that's good to hear.  I will merge the patch set later.
>
OK, sounds good!

> >
> >>>>
> >>>> 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
>
> Thank you for your understanding.  for now, please let me know the
> information of your extension once it's ready.

Please check my extension link:
https://github.com/liutgnu/mkdf-extension-amdgpu-mm-filtering

Thanks,
Tao Liu
>
> Thanks,
> Kazu