All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krister Johansen <kjlx@templeofstupid.com>
To: Tao Liu <ltao@redhat.com>
Cc: yamazaki-msmt@nec.com, k-hagio-ab@nec.com,
	kexec@lists.infradead.org, aravinda@linux.vnet.ibm.com,
	stephen.s.brennan@oracle.com
Subject: Re: [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering
Date: Mon, 22 Jun 2026 11:03:07 -0700	[thread overview]
Message-ID: <ajl422McaqugeWHs@templeofstupid.com> (raw)
In-Reply-To: <CAO7dBbVqBKmCzAXrRLvEOJg_+VjZOXxLkjfVkVHE0Emg976wew@mail.gmail.com>

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


  reply	other threads:[~2026-06-22 18:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 10:26 [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 1/9] Reserve sections for makedumpfile and extenions Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 2/9] Implement kernel kallsyms resolving Tao Liu
2026-06-15  8:09   ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-15 23:04     ` Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 3/9] Implement kernel btf resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 4/9] Implement kernel module's kallsyms resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 5/9] Implement kernel module's btf resolving Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 6/9] Add makedumpfile extensions support Tao Liu
2026-06-15  8:09   ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-15 17:12     ` Stephen Brennan
2026-06-15 23:03       ` Tao Liu
2026-06-16  1:39         ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-16  2:17           ` Tao Liu
2026-06-16  7:51             ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-16 10:31               ` Tao Liu
2026-06-17  1:50                 ` HAGIO KAZUHITO(萩尾 一仁)
2026-06-17  2:34                   ` Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 7/9] Add sample extension as an example reference Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 8/9] Doc: Add --extension option to makedumpfile manual Tao Liu
2026-04-14 10:26 ` [PATCH v5][makedumpfile 9/9] Add amdgpu mm pages filtering extension Tao Liu
2026-05-20  4:55 ` [PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering Tao Liu
2026-05-28 18:37 ` Stephen Brennan
2026-05-28 22:02   ` Tao Liu
2026-05-29 21:11 ` Krister Johansen
2026-06-01 23:12   ` Tao Liu
2026-06-02  0:47     ` Krister Johansen
2026-06-02  3:04       ` Tao Liu
2026-06-02  4:49         ` Krister Johansen
2026-06-11  1:24           ` Tao Liu
2026-06-22 18:03             ` Krister Johansen [this message]
2026-06-22 22:35               ` Tao Liu
2026-06-10 23:42 ` [PATCH] Add erase_sample extension as an data erase reference Tao Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ajl422McaqugeWHs@templeofstupid.com \
    --to=kjlx@templeofstupid.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=k-hagio-ab@nec.com \
    --cc=kexec@lists.infradead.org \
    --cc=ltao@redhat.com \
    --cc=stephen.s.brennan@oracle.com \
    --cc=yamazaki-msmt@nec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.