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

[Krister Johansen]

Hi Tao,

On Tue, Jun 02, 2026 at 03:04:12PM +1200, Tao Liu wrote:
> On Tue, Jun 2, 2026 at 12:47 PM Krister Johansen
> <kjlx at templeofstupid.com> wrote:
> Thanks for your in-depth explanation, it's very helpful to me for
> designing the data erasing function.

Thanks for the great discussion.

> > On Tue, Jun 02, 2026 at 11:12:05AM +1200, Tao Liu wrote:
> > > On Sat, May 30, 2026 at 9:11 AM Krister Johansen
> > 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?

This is a great point.  It's probably worth documenting the precedence
order in which these callbacks are expected to be applied.  Naively, I
might expect filtering pages to take precedence over erasing data
structures.  For the GPU cases, these are orthogonal.  However, for
something where a user might be both trying to filter the page and erase
matching content, we don't have any rules defined.  It's probably less
surprising to allow pages to be filtered first.  (I think it is this way
in the code.) It also prevents the page filtering from completely
filtering a page.

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

Just to clarify, I'm not asking that you implement any erase
functionality in the current patchset.  Rather, asking if there's a way
to implement the current functionality such that the extension modules
won't need recompilation when a new extension type is introduced. I
think there are a number of different ways to do this, but I didn't want
to be overly prescriptive in my feedback.

Thanks again,

-K