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

[Tao Liu]

Hi Krister,

On Tue, Jun 2, 2026 at 12:47 PM Krister Johansen
<kjlx at templeofstupid.com> wrote:
>
> Hi Tao,
> Thanks for the response! I've put the followups below.

Thanks for your in-depth explanation, it's very helpful to me for
designing the data erasing function.

>
> 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.

Yes, I totally agree.

>
> > > 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.

No worries, I didn't post the goals upstream; I only had internal
discussions within my team regarding the next steps for BTF/kallsyms
in makedumpfile.

>
> > 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)

Frankly I didn't consider the data erasing as in-depth as you did. I
think you are right, makedumpfile needs to know which extensions
handle data erasing and which handle mm page filtering. I guess the mm
page filtering extensions will need to perform a "dry-run" filter
first, in case the "data erasing" extensions break any useful data
structure. In this step, "dry-run" will only record pfn numbers of the
pages that will be filtered. Then "data erasing" extensions are
called, so all the sensitive data is memset to 0. Finally, all desired
pages are filtered out based on the previous recording.

With this, "data erase" and "page filtering" will not interfere with
each other. What do you think?

>
> > > 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?

I see your idea: makedumpfile predefines a few hook points at
different stages, and extensions can register their callbacks to these
hook points. For now I think 2 hook points are enough, one for page
filtering and other one for resiger the data erasing, which definitely
shouldn't be within __exclude_unnecessary_pages().

I'm willing to modify the code. Such as implementing a hooking point
registration/management. But since I haven't work on the data erasing
functions so far, the design might be superficial, personally I'd
prefer to do this along with the data erasing functions in the next
independent patchset, considering current patchset we already includes
plenty of code/function implementations. @maintainers, What's your
opinion?

>
> > > 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.

Agreed.

Thanks,
Tao Liu

>
> Thanks,
>
> -K
>