[PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering

[Krister Johansen]

Hi Tao,
Thanks for the response! I've put the followups below.

On Tue, Jun 02, 2026 at 11:12:05AM +1200, Tao Liu wrote:
> On Sat, May 30, 2026 at 9:11 AM Krister Johansen
> <kjlx at templeofstupid.com> wrote:
> >
> > I love this idea.  Do you have time to take it further, and if not are
> > you open to making the extension framework more modular so that we could
> > add others in the future?
> 
> The purpose of extension is to make the framework modular. My original
> thought is, we can implement several makedumpfile extensions, each
> restricted to one specific function. Like one extension deals with AMD
> gpu mm filtering only, one deals with Intel gpu only etc. For distros
> we can ship all extensions along with makedumpfile once, but the
> respective extensions will only take effect if the machine has AMD /
> Intel gpu. This is the same case if you'd like to add other customized
> functions while the makedumpfile core remains unchanged.

Makes sense.

> > Could the btf lookups be extended to cover the symbol lookups used by
> > eppic and the erase filters so that the -x option is unnecessary for
> > kernels that have BTF support?
> 
> Yes, from my view it is doable and not difficult to implement.

In some environments, the size of the vmlinux + modules can be fairly
substantial to leave on disk.  It's attractive to have the option to
omit it and still filter dumps.

> > The current extension implementation is focused just on skipping pages,
> > but it would be great to be able to use this to erase data in structures
> > like the config filters and eppic, but without having to provide a
> > vmlinux at dump time.  What do you think about adding the ability to
> > use the extensions to also erase parts of data structures, in addition
> > to filtering whole pages?
> 
> That's the step 2 for the BTF/kallsyms work of makedumpfile, and I
> have planed to work on this once the patchset(step 1) is accepted. The
> reason for the task dividing is, the GPU mm page filtering is more
> urgent than data erasing from my view. For data erasing, at least we
> can do the erasing in 1st kernel with the help of dwarf, cumbersome
> but working; For GPU mm filtering, as far as I know, there are no
> handy tools in 2nd kernel.

Excited to hear that you have something already planned for erasing.  My
apologies if I missed a more comprehensive write-up about the longer
term goals for the work.

> I think erasing the data is doable upon the current page filtering code.

I wondered about this, but for data-structures that are smaller than a
page, wouldn't that mean that we're erasing other content?  The "erase"
plugins memset the output data to a chosen value (or 0), whereas the
filtering just drops the page.  Couldn't this also lead to a situation
where the debugger can't find the page at all, versus giving us one
that's sanitized?  (I do understand why you want to drop the pages for
the GPU cases)

> > Would you be willing to modify the extension registration options to
> > allow an extension to specify what kind it is? That way, in the future
> 
> I'm not sure what you mean by "what kind". Do you mean an extension
> needs to tell makedumpfile what purpose it is for when loading?

Yes, sorry I wasn't clear in writing the question.  Stating this
differently, if we want to allow the ability for different extensions to
do different things, how do the extensions declare to makedumpfile what
they can do, so that it knows where to invoke their callbacks, and what
callbacks of theirs to invoke.

Looking at patch 6/9, right now run_extension_callback() is involved
from __exclude_unncessary_pages and always calls the
"extension_callback" symbol in the module.  This makes sense for a
single extension type that's focused on filtering pages.  However, if we
wanted to have multiple different extensions, this might be more
difficult.

If we could determine what type of functionality the module implements
in load_extensions, then we could tell if this is a page filtering
extension, an erase extension, or some other kind of extension.

For example, for an erase filter, perhaps we would want two callbacks:
one to set up the ranges to filter "extension_gather_callback" and
another to actuallyf check the address range to see if it is filtered,
"extension_filter_data_callback"

I'm not sure about the names.  "extension_callback" seems generic, but
this has a specific purpose.  It's a "extension_filter_page_callback"

I may be overengineering this a bit, but having makedumpfile pass an ops
vector to the extension in a load function could help here.  Then the
module's load function fills out the vector with the functions it
supports.  Depending on what's implemented, these can be placed into
different callback lists to get invoked at different points in the
program (e.g. one at pfn filter time, another in filter_data_buffer,
etc).

It sounds like you had a plan here, though.  Were you thinking of adding
new extension types a different way?

> > we could register multiple different kinds without breaking existing
> > ones.  One for filtering pages, one for erasing / modifying dump
> > content, and others based upon whatever additional use cases develop.
> 
> That's the goal of extensions, each extension deals with its own
> business. Could you point out the code that doesn't match the goal?
> I'm happy to correct it in v6.

Yes, I attempted to elaborate on this in the preceding paragraphs.
Basically wondering how we can add new extension functionality without
breaking existing extensions, and then get the code to invoke the right
if there are multiple types that need to be used at different times.

Thanks,

-K