On 2023/11/10 12:15, Tao Liu wrote:
> If a module already does not have its init memory range, it might
be
> a bit better to not specify "-s .init.text <addr>" to
add-symbol-file..
>
Thanks a lot for finding the root cause. My patch is just a
work-around, and I think your "trial" patch is better to be applied. I
agree the ".init.text" should not be added by add-symbol-file, since
this section will be freed and will be occupied by other modules after
kernel init, which will cause symbols overlap. Could you please draft
the "trial" patch to be the formal one?
The trial patch just doesn't add the .init.text unconditionally, but it
should be required occasionally e.g. a panic when module initialization?
As crash has a symbol table for a module init range:
crash> help -s
...
mod_base: ffffffffc0092000
module_struct: ffffffffc009db00
mod_name: floppy
mod_size: 69417
mod_namelist: /home/vmcore/symbol_err/...
mod_flags: 2a (MOD_LOAD_SYMS|MOD_KALLSYMS|MOD_NOPATCH)
mod_symtable: 6a28170
mod_symend: 6a2a268
mod_init_symtable: 0 <<<
mod_init_symend: 0 <<<
So to finish a patch, we will need to look into a few more things:
- It looks like the .init.{text,data} sections are always added on that
kernel version, whether this is intended or not. For example, they
might be wrongly added due to a name change of a struct member.
- If it's an intended behavior, how we can exclude the .init sections
only when it's unnecessary.
and etc. Could you take a look?
Thanks,
Kazu