[Crash-utility] About referring to struct load_module from extension modules

Hagio-san, crash trace now results in SIGSEGV on Fedora Linux 38 as follows: crash> extend /usr/lib64/crash/extensions/trace.so /usr/lib64/crash/extensions/trace.so: shared object loaded crash> trace current tracer is nop crash> trace show Segmentation fault (core dumped) The SIGSEGV occurs in function save_proc_kallsyms() when trying to look up module symbols via lm->mod_symtable: https://github.com/fujitsu/crash-trace/blob/master/trace.c#L2222-L2246 crash trace command creates a trace data that contains kallsyms internally. crash trace command refer to lm->mod_symtable to create the kallsyms. See https://man7.org/linux/man-pages/man5/trace-cmd.dat.5.html#KALLSYMS_INFOR... in details. This issue occurs when using crash utility with the following commit that is for new kernel module layout support on Linux kernel 6.4: commit 7750e61fdb2a083f26156a5338aa2ebe26447f3f Author: Kazuhito Hagio <k-hagio-ab(a)nec.com&gt; Date: Thu Jun 22 16:09:07 2023 +0900 Support module memory layout change on Linux 6.4 Support module memory layout change on Linux 6.4 by kernel commit ac3b43283923 ("module: replace module_layout with module_memory") [1]. Without the patch, crash cannot even start a session with an error message like this: crash: invalid structure member offset: module_core_size FILE: kernel.c LINE: 3787 FUNCTION: module_init() [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit... Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com&gt; I've already made a tentative fixing patch based on this new handling of struct load_module based on function module_symbol_dump() and it works fine. On the other hand, is it OK to refer to struct load_module directly from extension modules? I'm not the original author of crash trace command. I've just found crash trace doing like this for the first time. - If it is OK to refer to struct load_module directly from extension modules, should it be backward compatible on it? Or extension modules should absorb the incompatibility? - If it is not OK, is there possibility to introduce a new interface to iterate symbols without need of referring to struct load_modules directly? Thanks. HATAYAMA, Daisuke