[PATCH v5][makedumpfile 6/9] Add makedumpfile extensions support

[Tao Liu]

On Tue, Jun 16, 2026 at 1:39 PM HAGIO KAZUHITO(萩尾　一仁)
<k-hagio-ab at nec.com> wrote:
>
> On 2026/06/16 8:03, Tao Liu wrote:
> > Hi Stephen & Kazu,
> >
> > On Tue, Jun 16, 2026 at 5:12 AM Stephen Brennan
> > <stephen.s.brennan at oracle.com> wrote:
> >>
> >> HAGIO KAZUHITO(萩尾　一仁)   <k-hagio-ab at nec.com> writes:
> >>> On 2026/04/14 19:26, Tao Liu wrote:
> >>>
> >>>> +static bool init_kallsyms_btf(void)
> >>>> +{
> >>>> +    int count;
> >>>> +    bool ret = false;
> >>>> +    /* We will load module's btf/kallsyms on demand */
> >>>> +    bool init_ksyms_module = false;
> >>>> +    bool init_ktypes_module = false;
> >>>> +
> >>>> +    if (check_ksyms_require_modname("vmlinux", &count)) {
> >>>
> >>> Thank you for the explanation [1].
> >>>
> >>> so which code path adds "vmlinux" to the mods array before this line?
> >>> I could not find it.
> >>
> >> Hello Kazu,
> >>
> >> In kallsyms.c from patch 2, there is the line:
> >>    INIT_MOD_SYM(vmlinux, _stext);
> >> This adds a struct ksym_info to the main makedumpfile executable's
> >> array, which requests symbol "_stext" from vmlinux.
> >>
> >> In kallsyms.c "init_kernel_kallsyms()", again from patch 2, the first
> >> step is to call:
> >>     register_ksym_section((char *)__start_init_ksyms,
> >>                           (char *)__stop_init_ksyms))
> >> Which is a function generated by the macro REGISTER_SECTION(). The
> >> implementation will use add_ksym_modname() whens it encounters this
> >> symbol, ensuring that "vmlinux" is part of the modname array.
> >
> > Thanks for the detailed info, yes, it is exactly how "vmlinux" is
> > added to the array.
>
> hmm, maybe I still misread it though..
>
> The init_kernel_kallsyms() is called _after_ check_ksyms_require_modname().
> so I've meant that if no extension adds "vmlinux" to the modname array,
> no one calls it.  is it ok?
>
>          if (check_ksyms_require_modname("vmlinux", &count)) {
>                  if (!init_kernel_kallsyms())

No, even if you create a extension which doesn't require symbols from
"vmlinux", once you load it, the check_ksyms_require_modname() will
still be true and init_kernel_kallsyms() is called.

The reason is, with the introduction of makedumpfile.ld, and the line
"INIT_MOD_SYM(vmlinux, _stext);" in kallsyms.c, makedumpfile and
extensions have a similar section structure, you can regard
makedumpfile itself as an extension:

$ readelf -S makedumpfile | grep -E 'ksyms|ktypes'
  [25] .init_ksyms       PROGBITS         000000000046ee90  0006de90
  [26] .init_ktypes      PROGBITS         000000000046eeb8  0006deb8
$ readelf -S extensions/sample.so | grep -E 'ksyms|ktypes'
  [24] .init_ksyms       PROGBITS         0000000000003108  00002108
  [25] .init_ktypes      PROGBITS         0000000000003110  00002110

If makedumpfile doesn't load any extensions, then makedumpfile doesn't
need to initialize its .init_ksyms/ktypes section, the behaviour stays
the same as before;
If makedumpfile load at least one extensions, then the extension
subsystem will register all .init_ksyms/ktypes sections, both
extenison's and makedumpfile's.

This is like, extension say "I need sym1 & sym2 to be ready before I
can run", then makedumpfile say "OK, I got it, but before I can
resolve your sym1 & sym2, I need to resolve some symbol(e.g. vmlinux's
_stext) formyself first". So check_ksyms_require_modname("vmlinux",
&count) will be true.

Hope this helps.

Thanks,
Tao Liu


>
> Thanks,
> Kazu
>
> >
> >>
> >> Thanks,
> >> Stephen
> >>
> >>> [1] https://lore.kernel.org/kexec/CAO7dBbUa_8H0fe+9bTNTQWjMVy9qCPiu0fo3g8XamiDS_Mr8eA@mail.gmail.com/
> >>>
> >>>
> >>>> +
> >>>> +bool has_extension_loaded(void)
> >>>> +{
> >>>> +    return extension_opts_len > 0;
> >>>
> >>> If an extension is skipped, this looks > 0 with no extention.
> >>> handle_cbs_len is better?
> >
> > Yeah, I agree, `has_extension_loaded()` should also be updated to
> > `has_extension_callback()`. I will fix it in v6.
> >
> > Thanks,
> > Tao Liu
> >
> >>>
> >>>
> >>> Thanks,
> >>> Kazu
> >>