Re: [Crash-utility] About referring to struct load_module from extension modules
On 2023/09/26 19:21, Daisuke Hatayama (Fujitsu) wrote:
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>
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>
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?
Yes, I think it's ok.
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?
The crash-utility considers extension modules somewhat (e.g. [1]), but
AFAIK there is no other strict rule about the compatibility. We cannot
know what is used by extension modules. If crash has to keep their
backward-compatibility, all global variables and functions have to be
compatible. That will make crash development inefficient or maybe
sometimes impossible depending on a kernel change. So I think that
crash changes should be handled by extension modules, same as kernel
changes.
[1] https://github.com/crash-utility/crash/wiki#writing-patches
Thanks,
Kazu
>
> - 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