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

Krister Johansen kjlx at templeofstupid.com
Mon Jun 22 11:03:07 PDT 2026


Hi Tao,
I appreciate your additional investigation on these questions.

On Thu, Jun 11, 2026 at 01:24:50PM +1200, Tao Liu wrote:
> Hi Krister,
> 
> I took some time to think about the data erase functions as we
> discussed previously, and I have implemented one sample data eraser
> based on the current v5 extension framework in [1]. According to my
> test, this works well and has no conflict with the mm page filtering
> extensions. With this, people can do data erasure as well as page
> filtering in both 1st/2nd kernel as long as btf/kallsyms info is
> accessiable.

I took a look at the example in your subsequent e-mail.  I think this
would work for what I'm trying to.  I didn't realize that the extension
callbacks you built had the ability to call into the other erase code
that's also available to eppic.

> As for btf/kallsyms support for makedumpfile.conf based erasure, I
> forgot to mention there is one critical info missing compare with "-x
> vmlinux" dwarfinfo, is the type of global variables, please see the
> patch [2]. As far as I know, currently kernel hasn't enabled the btf's
> ability of including global variable's types. E.g. symbol "init_task",
> we can only know its address by lookup kallsyms, but btf have no
> record if its type, because it is a global variable. If we create
> makedumpfile.conf as follows:
> 
> [vmlinux]
> erase init_task
> 
> It can work with no problem for "-x vmlinux" because dwarfinfo
> contains all info. But it will fail to btf/kallsyms, for btf doesn't
> know init_task's type is task_struct. However this is not a problem
> for makedumpfile extensions, because when programming, we can cast it
> as task_struct by "init_task = GET_KERN_SYM(init_task); task_list =
> init_task + KERN_MEMBER_OFF(task_struct, tasks); ...",  but we cannot
> do the same to makedumpfile.conf.
 
Got it.  It wouldn't work with the current configuration file syntax
because it needs more information to pass to the APIs that perform the
btf lookup?  Trying to understand if GET_KERN_SYM can be dynamically
filled in, or if its a macro that's evaluated at compile time and isn't
dynamically changable.

Thanks again,

-K



More information about the kexec mailing list