5:21 a.m.
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?
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
7:03 p.m.
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
11:10 p.m.
Hagio-san,
Sorry for the delayed response.
________________________________________
From: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
Sent: Thursday, September 28, 2023 9:03
To: Hatayama, Daisuke/畑山 大輔
Cc: crash-utility(a)redhat.com
Subject: Re: About referring to struct load_module from extension modules
On 2023/09/26 19:21, Daisuke Hatayama (Fujitsu) wrote:
...snip...
> 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
Thank you for your suggestion.
I agree to you because:
- The bad effect for development and maintenance of crash utility is
not preferable also for extension modules.
- Module layout changes that affect crash utility thus far appears
rare according to the source code; the module layout change is v3.
- It is easy for crash trace to deal with the module layout change
this time.
On the other hand, there could be the change in crash utility where
it's difficult for extension modules to deal with in the future. In
that case, I'll discuss them as necessary.
Thanks.
HATAYAMA, Daisuke
1:37 a.m.
On 2023/10/02 13:10, Daisuke Hatayama (Fujitsu) wrote:
Hagio-san,
Sorry for the delayed response.
> ________________________________________
> From: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
> Sent: Thursday, September 28, 2023 9:03
> To: Hatayama, Daisuke/畑山 大輔
> Cc: crash-utility(a)redhat.com
> Subject: Re: About referring to struct load_module from extension modules
>
> On 2023/09/26 19:21, Daisuke Hatayama (Fujitsu) wrote:
...snip...
>> 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
Thank you for your suggestion.
I agree to you because:
- The bad effect for development and maintenance of crash utility is
not preferable also for extension modules.
- Module layout changes that affect crash utility thus far appears
rare according to the source code; the module layout change is v3.
- It is easy for crash trace to deal with the module layout change
this time.
Thank you for understanding.
On the other hand, there could be the change in crash utility where
it's difficult for extension modules to deal with in the future. In
that case, I'll discuss them as necessary.
Yes, sure, there will be some cases where crash has to have changes so
that extension modules can work, like commit 2f1085df4dc9 ("EPPIC
extension support for crash-8.x + gdb-10.x").
Thanks,
Kazu
350
days inactive
356
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Daisuke Hatayama (Fujitsu) -
HAGIO KAZUHITO(萩尾 一仁)