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_INFORMATION > 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@xxxxxxx> > 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/?id=ac3b43283923 > > Signed-off-by: Kazuhito Hagio <k-hagio-ab@xxxxxxx> > > 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
