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

Hi Krister,

On Tue, Jun 23, 2026 at 6:03 AM Krister Johansen
<[email protected]> wrote:
>
> 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.

Thank you for raising the data erasure issue, to be honest I hadn't
thought about it in depth before your message.

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

Yes, because currently, no BTF info is integrated for global kernel
variables. That is, we can only know global variable's address by
kallsyms, but no type info from BTF. If we try to build
makedumpfile.conf erasure upon btf, it should be something like:

[vmlinux]
erase (struct task_struct)init_task

To be honest, the syntax will be ugly, and I'd prefer the issue fixed
on the kernel side rather than in makedumpfile.conf side. As for why
kernel hasn't enable the global variable's btf info, that's another
story and should be addressed individually.

> filled in, or if its a macro that's evaluated at compile time and isn't
> dynamically changable.

When macros such as INIT_MOD_SYM(vmlinux, init_task) are used, a
special elf section will be reserved for the extension .so at compile
time, this indicates the extension needs this kernel symbol before it
can run. When makedumpfile parses the kernel's btf/kallsyms, these
special sections will be filled with their respective values. After
this, the extension is runnable, by using GET_KERN_SYM() macro, the
values will be retrived from the special section and developers can
use it directly.

Thanks,
Tao Liu


>
> Thanks again,
>
> -K
>