April 2024 - Crash-utility - Crash Utility List Archives

Re: [PATCH v4 ] Adding the zram decompression algorithm "lzo-rle" to support kernel versions >= 5.1

by HAGIO KAZUHITO(萩尾　一仁)

On 2024/03/28 17:15, Yulong TANG 汤玉龙 wrote: > In Linux 5.1, the ZRAM block driver has changed its default compressor > from "lzo" to "lzo-rle" to enhance LZO compression support. However, > crash does not support the improved LZO algorithm, resulting in failure > when reading memory. > > change default compressor : ce82f19fd5809f0cf87ea9f753c5cc65ca0673d6 > > The issue was discovered when using the extension 'gcore' to generate a > process coredump, which was found to be incomplete and unable to be > opened properly with gdb. > This patch is for Crash-utility tool, it enables the Crash-utility to > support decompression of the "lzo-rle" compression algorithm used in > zram. The patch has been tested with vmcore files from kernel version > 5.4, and successfully allows reading of memory compressed with the zram > compression algorithm. > > Testing: > ======== > > before apply this patch : > crash> gcore -v 0 1 > gcore: WARNING: only the lzo compressor is supported > gcore: WARNING: only the lzo compressor is supported > gcore: WARNING: only the lzo compressor is supported > after: > crash> gcore -v 0 > 1 Saved core.1.init > > Changelog: > ========== > v2: keep the "if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)" > related code of the copied kernel code, but change the "if defined" > macro into a runtime check . > v3: set a default value of HAVE_EFFICIENT_UNALIGNED_ACCESS depending on > architecture, for no ikconfig kernels. > v4: avoid checking CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS every > call；move "include lzorle_decompress.h" to diskdump.c from def.h thank you for the update. The patch tested OK with lzo-rle zram, but I found a small issue and redundant codes, and fixed them. Could you check the attached patch again? * "make ctags" didn't work for lzorle_decompress.h, so added it to SOURCE_FILES. * There was no need to include stdint.h and string.h in lzorle_decompress.c, so removed them. * There are the same code blocks in "if (efficient_unligned_access)" block and else block. Isn't this ok? if (efficient_unaligned_access && (HAVE_IP(t + 15) && HAVE_OP(t + 15))) { * Why are NEED_IP() and etc. new-lined? Replaced them with one lines like the original kernel code. #define NEED_IP(x) if (!HAVE_IP(x)) goto input_overrun #define NEED_OP(x) if (!HAVE_OP(x)) goto output_overrun #define TEST_LB(m_pos) if ((m_pos) < out) goto lookbehind_overrun Thanks, Kazu > > Patch: > ========== > > See attachment. > > > > Thanks and regards, > Yulong > > > -- > Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io > To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io > https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ > Contribution Guidelines: https://github.com/crash-utility/crash/wiki

5 months, 3 weeks

2
1
0 / 0

[PATCH] x86_64: rhel 9.3: "crash" doesn't handle all IRQ exception properly.

by Aureau, Georges (Kernel Tools ERT)

Hello, On x86_64, with rhel 9.3, there are cases where "crash" can't handle IRQ exception frames properly. For example, "crash" fails with "WARNING: possibly bogus exception frame": crash> bt -c 30 PID: 2898241 TASK: ff4cb0ce0da0c680 CPU: 30 COMMAND: "star-ccm+" #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8 #1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab #2 [fffffe4658d88eb0] default_do_nmi at ffffffffa0c56cd0 #3 [fffffe4658d88ed0] exc_nmi at ffffffffa0c56ee1 #4 [fffffe4658d88ef0] end_repeat_nmi at ffffffffa0e01639 [exception RIP: native_queued_spin_lock_slowpath+636] RIP: ffffffffa0c6b80c RSP: ff5eba269937ce10 RFLAGS: 00000046 RAX: 0000000000000000 RBX: ff4cb12bcfbb2940 RCX: 00000000007c0000 RDX: 0000000000000057 RSI: 0000000001600000 RDI: ff4cb12d67205608 RBP: ff4cb12d67205608 R8: ff90b9c682475940 R9: 0000000000000000 R10: ff4cb0d70ee4e100 R11: 0000000000000000 R12: 0000000000000000 R13: 000000000000001e R14: ff90b9c682474918 R15: ff90b9c682477120 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- <NMI exception stack> --- #5 [ff5eba269937ce10] native_queued_spin_lock_slowpath at ffffffffa0c6b80c #6 [ff5eba269937ce30] _raw_spin_lock_irqsave at ffffffffa0c6ad90 #7 [ff5eba269937ce40] free_iova at ffffffffa07df716 #8 [ff5eba269937ce68] fq_ring_free at ffffffffa07dba15 #9 [ff5eba269937ce98] fq_flush_timeout at ffffffffa07dc8fe #10 [ff5eba269937ced0] call_timer_fn at ffffffffa01c00a4 #11 [ff5eba269937cef0] __run_timers at ffffffffa01c03ae #12 [ff5eba269937cf88] run_timer_softirq at ffffffffa01c0476 #13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007 #14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61 #15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2 --- <IRQ stack> --- RIP: 0000000000000010 RSP: 0000000000000018 RFLAGS: ff5eba26ddc9f7e8 RAX: 0000000000000a20 RBX: ff5eba26ddc9f940 RCX: 0000000000001000 RDX: ffffffb559980000 RSI: ff4cb12d67207400 RDI: ffffffffffffffff RBP: 0000000000001000 R8: ff5eba26ddc9f940 R9: ff5eba26ddc9f8af R10: 0000000000000003 R11: 0000000000000a20 R12: ff5eba26ddc9f8b0 R13: 000000283c07f000 R14: ff4cb0f5a29a1c00 R15: 0000000000000001 ORIG_RAX: ffffffffa07c4e60 CS: 0206 SS: 7000001cf0380001 bt: WARNING: possibly bogus exception frame Running "crash" with "--machdep irq_eframe_link=0xffffffffffffffe8" (ie. thus irq_eframe_link = -24) works properly: PID: 2898241 TASK: ff4cb0ce0da0c680 CPU: 30 COMMAND: "star-ccm+" #0 [fffffe4658d88e58] crash_nmi_callback at ffffffffa00675e8 #1 [fffffe4658d88e68] nmi_handle at ffffffffa002ebab #2 [fffffe4658d88eb0] default_do_nmi at ffffffffa0c56cd0 #3 [fffffe4658d88ed0] exc_nmi at ffffffffa0c56ee1 #4 [fffffe4658d88ef0] end_repeat_nmi at ffffffffa0e01639 [exception RIP: native_queued_spin_lock_slowpath+636] RIP: ffffffffa0c6b80c RSP: ff5eba269937ce10 RFLAGS: 00000046 RAX: 0000000000000000 RBX: ff4cb12bcfbb2940 RCX: 00000000007c0000 RDX: 0000000000000057 RSI: 0000000001600000 RDI: ff4cb12d67205608 RBP: ff4cb12d67205608 R8: ff90b9c682475940 R9: 0000000000000000 R10: ff4cb0d70ee4e100 R11: 0000000000000000 R12: 0000000000000000 R13: 000000000000001e R14: ff90b9c682474918 R15: ff90b9c682477120 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- <NMI exception stack> --- #5 [ff5eba269937ce10] native_queued_spin_lock_slowpath at ffffffffa0c6b80c #6 [ff5eba269937ce30] _raw_spin_lock_irqsave at ffffffffa0c6ad90 #7 [ff5eba269937ce40] free_iova at ffffffffa07df716 #8 [ff5eba269937ce68] fq_ring_free at ffffffffa07dba15 #9 [ff5eba269937ce98] fq_flush_timeout at ffffffffa07dc8fe #10 [ff5eba269937ced0] call_timer_fn at ffffffffa01c00a4 #11 [ff5eba269937cef0] __run_timers at ffffffffa01c03ae #12 [ff5eba269937cf88] run_timer_softirq at ffffffffa01c0476 #13 [ff5eba269937cf90] __do_softirq at ffffffffa0c6c007 #14 [ff5eba269937cfe0] __irq_exit_rcu at ffffffffa010ef61 #15 [ff5eba269937cff0] sysvec_apic_timer_interrupt at ffffffffa0c58ca2 --- <IRQ stack> --- #16 [ff5eba26ddc9f738] asm_sysvec_apic_timer_interrupt at ffffffffa0e00e06 [exception RIP: alloc_pte.constprop.0+32] RIP: ffffffffa07c4e60 RSP: ff5eba26ddc9f7e8 RFLAGS: 00000206 RAX: ff5eba26ddc9f940 RBX: 0000000000001000 RCX: 0000000000000a20 RDX: 0000000000001000 RSI: ffffffb559980000 RDI: ff4cb12d67207400 RBP: ff5eba26ddc9f8b0 R8: ff5eba26ddc9f8af R9: 0000000000000003 R10: 0000000000000a20 R11: ff5eba26ddc9f940 R12: 000000283c07f000 R13: ff4cb0f5a29a1c00 R14: 0000000000000001 R15: ff4cb0f5a29a1bf8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #17 [ff5eba26ddc9f830] iommu_v1_map_pages at ffffffffa07c5648 #18 [ff5eba26ddc9f8f8] __iommu_map at ffffffffa07d7803 #19 [ff5eba26ddc9f990] iommu_map_sg at ffffffffa07d7b71 #20 [ff5eba26ddc9f9f0] iommu_dma_map_sg at ffffffffa07ddcc9 #21 [ff5eba26ddc9fa90] __dma_map_sg_attrs at ffffffffa01b5205 #22 [ff5eba26ddc9fa98] dma_map_sgtable at ffffffffa01b526d #23 [ff5eba26ddc9faa8] ib_umem_get at ffffffffc112f308 [ib_uverbs] #24 [ff5eba26ddc9fb00] mlx5_ib_reg_user_mr at ffffffffc11eb991 [mlx5_ib] #25 [ff5eba26ddc9fb40] ib_uverbs_reg_mr at ffffffffc1123bc4 [ib_uverbs] #26 [ff5eba26ddc9fbb0] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE at ffffffffc112d064 [ib_uverbs] #27 [ff5eba26ddc9fbe0] ib_uverbs_run_method at ffffffffc112a121 [ib_uverbs] #28 [ff5eba26ddc9fc30] ib_uverbs_cmd_verbs at ffffffffc112a332 [ib_uverbs] #29 [ff5eba26ddc9fe68] ib_uverbs_ioctl at ffffffffc112a494 [ib_uverbs] #30 [ff5eba26ddc9fea8] __x64_sys_ioctl at ffffffffa0438f67 #31 [ff5eba26ddc9fed8] do_syscall_64 at ffffffffa0c55189 #32 [ff5eba26ddc9ff50] entry_SYSCALL_64_after_hwframe at ffffffffa0e000ea RIP: 0000146ef3a3ec6b RSP: 00007ffe3b7dc5b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007ffe3b7dc6a8 RCX: 0000146ef3a3ec6b RDX: 00007ffe3b7dc690 RSI: 00000000c0181b01 RDI: 0000000000000011 RBP: 00007ffe3b7dc670 R8: 0000146ed9549010 R9: 00007ffe3b7dc7c4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe3b7dc7c4 R13: 000000000000000c R14: 000000000000000c R15: 0000146ed9549150 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b Some background: asm_common_interrupt: callq error_entry movq %rax,%rsp movq %rsp,%rdi movq 0x78(%rsp),%rsi movq $-0x1,0x78(%rsp) call common_interrupt # rsp pointing to regs common_interrupt pushq %r12 pushq %rbp pushq %rbx [...] movq hardirq_stack_ptr,%r11 movq %rsp,(%r11) movq %r11,%rsp [...] call __common_interrupt # rip:common_interrupt So frame_size(rip:common_interrupt) = 32 (3 push + ret). Hence "machdep->machspec->irq_eframe_link = -32;" (see x86_64_irq_eframe_link_init()). Now: asm_sysvec_apic_timer_interrupt: pushq $-0x1 callq error_entry movq %rax,%rsp movq %rsp,%rdi callq sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt pushq %r12 pushq %rbp [...] movq hardirq_stack_ptr,%r11 movq %rsp,(%r11) movq %r11,%rsp [...] call __sysvec_apic_timer_interrupt # rip:sysvec_apic_timer_interrupt Here frame_size(rip:sysvec_apic_timer_interrupt) = 24 (2 push + ret) We should also notice that: rip = *(hardirq_stack_ptr - 8) rsp = *(hardirq_stack_ptr) regs = rsp - frame_size(rip) But x86_64_get_framesize() does not work with IRQ handlers (returns 0). So not many options other than hardcoding the most likely value and looking around it. Actually x86_64_irq_eframe_link() was trying -32 (default), and then -40, but not -24 ! Signed-off-by: Georges Aureau <georges.aureau(a)hpe.com> -- diff --git a/x86_64.c b/x86_64.c index aec82b0..90c2a91 100644 --- a/x86_64.c +++ b/x86_64.c @@ -6623,13 +6623,14 @@ x86_64_irq_eframe_link_init(void) /* * Calculate and verify the IRQ exception frame location from the - * stack reference at the top of the IRQ stack, possibly adjusting - * the ms->irq_eframe_link value. + * stack reference at the top of the IRQ stack, keep ms->irq_eframe_link + * as the most likely value, and try a few sizes around it. */ static ulong x86_64_irq_eframe_link(ulong stkref, struct bt_info *bt, FILE *ofp) { ulong irq_eframe; + int i, try[] = { 8, -8, 16, -16 }; if (x86_64_exception_frame(EFRAME_VERIFY, stkref, 0, bt, ofp)) return stkref; @@ -6639,9 +6640,10 @@ x86_64_irq_eframe_link(ulong stkref, struct bt_info *bt, FILE *ofp) if (x86_64_exception_frame(EFRAME_VERIFY, irq_eframe, 0, bt, ofp)) return irq_eframe; - if (x86_64_exception_frame(EFRAME_VERIFY, irq_eframe+8, 0, bt, ofp)) { - machdep->machspec->irq_eframe_link -= 8; - return (irq_eframe + 8); + for (i=0; i<sizeof(try)/sizeof(int); i++) { + if (x86_64_exception_frame(EFRAME_VERIFY, irq_eframe+try[i], 0, bt, ofp)) { + return (irq_eframe + try[i]); + } } return irq_eframe;

5 months, 3 weeks

1
0
0 / 0

[Crash-Utility][PATCH v2] symbols.c: skip non-exist module memory type

by Tao Liu

Not all mod_mem_type will be included for kernel modules. E.g. in the following module case: (gdb) p lm->symtable[0] $1 = (struct syment *) 0x4dcbad0 (gdb) p lm->symtable[1] $2 = (struct syment *) 0x4dcbb70 (gdb) p lm->symtable[2] $3 = (struct syment *) 0x4dcbc10 (gdb) p lm->symtable[3] $4 = (struct syment *) 0x0 (gdb) p lm->symtable[4] $5 = (struct syment *) 0x4dcbcb0 (gdb) p lm->symtable[5] $6 = (struct syment *) 0x4dcbd00 (gdb) p lm->symtable[6] $7 = (struct syment *) 0x0 (gdb) p lm->symtable[7] $8 = (struct syment *) 0x4dcbb48 mod_mem MOD_RO_AFTER_INIT(3) and MOD_INIT_RODATA(6) is not exist, which should be skipped, otherwise a segfault will happen. Fixes: 7750e61fdb2a ("Support module memory layout change on Linux 6.4") Signed-off-by: Tao Liu <ltao(a)redhat.com> Reported-by: Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com> --- v1 -> v2: Keep the same code style as other similar iteration/checking cases. --- symbols.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/symbols.c b/symbols.c index cbc9ed1..b7627a8 100644 --- a/symbols.c +++ b/symbols.c @@ -5577,6 +5577,9 @@ value_search_module_6_4(ulong value, ulong *offset) continue; for_each_mod_mem_type(t) { + if (!lm->symtable[t]) + continue; + sp = lm->symtable[t]; sp_end = lm->symend[t]; -- 2.40.1

5 months, 3 weeks

2
2
0 / 0

Re: How to get module symbols working ?

by naveenchaudhary2010＠hotmail.com

Can someone please give some pointers. Adding some more details, the module name is "npdereference.ko" and the function where the crash is done looks like below. So I expect "null_deref_module_init" to be present instead of "_MODULE_INIT_TEXT_START_npdereference" : static int __init null_deref_module_init(void) { // Pointer to an integer, initialized to NULL int *null_pointer = NULL; printk(KERN_INFO "Null dereference module loaded\n"); // Dereferencing the NULL pointer to trigger a crash printk(KERN_INFO "Triggering null pointer dereference...\n"); *null_pointer = 1; // This line will cause a null pointer dereference return 0; // This will never be reached }

5 months, 3 weeks

1
0
0 / 0

Re: [Crash-Utility][PATCH] symbols.c: skip non-exist module memory type

by Tao Liu

Hi Naveen, On Tue, Apr 2, 2024 at 3:17 PM Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com> wrote: > > Thanks Tao, > > On a funny side, though I didn't understand this area of code much, but I ironically made the exact same fix to avoid problem for time being on my side, thinking there might be a different fix coming 🙂. Glad its now taken care. Thanks 🙂 > IMHO this is the right fix. If you look through the crash code, there are plenty of cases like: for_each_mod_mem_type(t) { if (!lm->symtable[t]) continue; So it shouldn't be an exception here. Just my opinion, let's see how other people think of it. If you want to know more about the background, you can check the patchset 7750e61fdb2a ("Support module memory layout change on Linux 6.4"), which will give you more info. In addition, please feel free to post your code, even if you are not very confident of it. The mailing list is open for discussion :) Thanks, Tao Liu > Regards, > Naveen > > > ________________________________ > From: Tao Liu <ltao(a)redhat.com> > Sent: Tuesday, April 2, 2024 12:15 PM > To: devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io> > Cc: Tao Liu <ltao(a)redhat.com>; Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com> > Subject: [Crash-Utility][PATCH] symbols.c: skip non-exist module memory type > > Not all mod_mem_type will be included for kernel modules. E.g. in the > following module case: > > (gdb) p lm->symtable[0] > $1 = (struct syment *) 0x4dcbad0 > (gdb) p lm->symtable[1] > $2 = (struct syment *) 0x4dcbb70 > (gdb) p lm->symtable[2] > $3 = (struct syment *) 0x4dcbc10 > (gdb) p lm->symtable[3] > $4 = (struct syment *) 0x0 > (gdb) p lm->symtable[4] > $5 = (struct syment *) 0x4dcbcb0 > (gdb) p lm->symtable[5] > $6 = (struct syment *) 0x4dcbd00 > (gdb) p lm->symtable[6] > $7 = (struct syment *) 0x0 > (gdb) p lm->symtable[7] > $8 = (struct syment *) 0x4dcbb48 > > mod_mem MOD_RO_AFTER_INIT(3) and MOD_INIT_RODATA(6) is not exist, which should > be skipped, otherwise a segfault will happen. > > Fixes: 7750e61fdb2a ("Support module memory layout change on Linux 6.4") > > Signed-off-by: Tao Liu <ltao(a)redhat.com> > Reported-by: Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com> > --- > symbols.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/symbols.c b/symbols.c > index cbc9ed1..27e55c6 100644 > --- a/symbols.c > +++ b/symbols.c > @@ -5580,7 +5580,7 @@ value_search_module_6_4(ulong value, ulong *offset) > sp = lm->symtable[t]; > sp_end = lm->symend[t]; > > - if (value < sp->value || value > sp_end->value) > + if (!sp || value < sp->value || value > sp_end->value) > continue; > > splast = NULL; > -- > 2.40.1 >

5 months, 4 weeks

2
4
0 / 0

[RFC PATCH 0/9] Add feature to validate page descriptor table in kdump-compressed format

by HATAYAMA Daisuke

I've made a RFC patch set to make sanity check of page descriptor table in kdump compressed format strict. This work has arose from the past issue that a produced crash dump file was broken not only in data segment but also in headers including page descriptor table. I've ever explained a bit this on crash-devel in the following thread: https://listman.redhat.com/archives/crash-utility/2023-September/010957.html In this past issue, I couldn't find out its root cause after all because when I began investigating the issue, problematic system where the issue was reproduced was already unavailable. This patch set is aimed at allowing us to figure out this kind of issue more quickly and in more detail using crash utility. The code is based on the tool I made to analyze the broken crash dump in the past issue. This is still incomplete, for example, the sanity check has not yet supported split dump files in the kdump-compressed format and old header version up to 5. It would be appreciated if I can get comments for this RFC version. HATAYAMA Daisuke (9): diskdump: Add stat object in diskdump_data diskdump: Add function sanity_check_page_desc() that sanity checks an entry of page descriptor table diskdump: Add function check_kdump_headers() that validates page descriptor table defs.h: Introduce flag VALIDATE_KDUMP_HEADERS diskdump, main: Add --validate_kdump_headers command-line option diskdump: Make sanity check in cache_page() strict help: Add description of --validate_kdump_headers command-line option man: Add description of --validate_kdump_headers command-line option diskdump, debug: Print elapsed time consumed in validation of page descriptor table crash.8 | 4 +++ defs.h | 1 + diskdump.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++- help.c | 4 +++ main.c | 5 ++++ 5 files changed, 87 insertions(+), 1 deletion(-) -- 2.43.1

5 months, 4 weeks

2
10
0 / 0

How to get module symbols working?

by Naveen Chaudhary

I am analyzing the kdump in latest crash utility 8.0.4++. I think I loaded the module symbols correctly : crash> mod MODULE NAME TEXT_BASE SIZE OBJECT FILE ffff80007a7e2040 npdereference ffff80007a7e0000 12288 (not loaded) [CONFIG_KALLSYMS] crash> crash> mod -s npdereference /home/naveen/.repos/src/arm64/linux/drivers/naveen/npdereference.ko MODULE NAME TEXT_BASE SIZE OBJECT FILE ffff80007a7e2040 npdereference ffff80007a7e0000 12288 /home/naveen/.repos/src/arm64/linux/drivers/naveen/npdereference.ko But still my backtrace doesn't say the correct symbol name : #12 [ffff800082c6ba60] _MODULE_INIT_TEXT_START_npdereference at ffff80007a7e602c [npdereference] The module name is "npdereference.ko" and the function where the crash is done looks like below. So I expect "null_deref_module_init" to be present instead of "_MODULE_INIT_TEXT_START_npdereference" : static int __init null_deref_module_init(void) { // Pointer to an integer, initialized to NULL int *null_pointer = NULL; printk(KERN_INFO "Null dereference module loaded\n"); // Dereferencing the NULL pointer to trigger a crash printk(KERN_INFO "Triggering null pointer dereference...\n"); *null_pointer = 1; // This line will cause a null pointer dereference return 0; // This will never be reached } The "sym" command also doesn't point me to the source file : crash> sym ffff80007a7e602c ffff80007a7e602c (m) _MODULE_INIT_TEXT_START_npdereference+44 [npdereference] crash> Is there a way to make this work correctly. The kernel module here is called "npdereference.ko" and is in-tree (part of kernel source repo). Regards, Naveen

5 months, 4 weeks

1
0
0 / 0

How to get module symbols working ?

by Naveen Chaudhary

I am analyzing the kdump in latest crash utility 8.0.4++. I think I loaded the module symbols correctly : crash> mod MODULE NAME TEXT_BASE SIZE OBJECT FILE ffff80007a7e2040 npdereference ffff80007a7e0000 12288 (not loaded) [CONFIG_KALLSYMS] crash> crash> mod -s npdereference /home/naveen/.repos/src/arm64/linux/drivers/naveen/npdereference.ko MODULE NAME TEXT_BASE SIZE OBJECT FILE ffff80007a7e2040 npdereference ffff80007a7e0000 12288 /home/naveen/.repos/src/arm64/linux/drivers/naveen/npdereference.ko But still my backtrace doesn't say the correct symbol name : #12 [ffff800082c6ba60] _MODULE_INIT_TEXT_START_npdereference at ffff80007a7e602c [npdereference] The "sym" command also doesn't point me to the source file : crash> sym ffff80007a7e602c ffff80007a7e602c (m) _MODULE_INIT_TEXT_START_npdereference+44 [npdereference] crash> Is there a way to make this work correctly or at least make the "sym" command point to right source file. The kernel module here is called "npdereference.ko" and is in-tree (part of kernel source repo). Regards, Naveen

5 months, 4 weeks

1
0
0 / 0

Re: [PATCH] gdb: fix the "p" command incorrectly print the value of a global variable

by Lianbo Jiang

Hi, Kazu and Tao Could you please have a look? or Any comments? Thanks Lianbo On 3/6/24 16:06, devel-request(a)lists.crash-utility.osci.io wrote: > Date: Wed, 6 Mar 2024 14:31:27 +0800 > From: Lianbo Jiang<lijiang(a)redhat.com> > Subject: [Crash-utility] [PATCH] gdb: fix the "p" command incorrectly > print the value of a global variable > To:devel@lists.crash-utility.osci.io > Message-ID:<20240306063127.477337-1-lijiang(a)redhat.com> > Content-Type: text/plain; charset="US-ASCII"; x-default=true > > Some objects format may potentially support copy relocations, but > currently the maybe_copied is always initialized to 0 in the symbol(). > And the type is 'mst_file_bss', not always the 'mst_bss' or 'mst_data' > in the lookup_minimal_symbol_linkage(). For example: > > (gdb) p *msymbol > $42 = {<general_symbol_info> = {m_name = 0x349812f "test_no_static", value = {ivalue = 8, block = 0x8, > bytes = 0x8 <error: Cannot access memory at address 0x8>, address = 8, common_block = 0x8, chain = 0x8}, language_specific = { > obstack = 0x0, demangled_name = 0x0}, m_language = language_auto, ada_mangled = 0, section = 20}, size = 4, > filename = 0x6db3440 "test_sanity.c", type = mst_file_bss, created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size = 1, > maybe_copied = 0, name_set = 1, hash_next = 0x0, demangled_hash_next = 0x0} > > This causes a problem that the 'p' command can not work well as > expected, and always gets an error: > > crash> mod -s test_sanity /home/test_sanity.ko > MODULE NAME BASE SIZE OBJECT FILE > ffffffffc1084040 test_sanity ffffffffc1082000 16384 /home/test_sanity.ko > crash> p test_no_static > p: gdb request failed: p test_no_static > crash> > > With the patch: > crash> mod -s test_sanity /home/test_sanity.ko > MODULE NAME BASE SIZE OBJECT FILE > ffffffffc1084040 test_sanity ffffffffc1082000 16384 /home/test_sanity.ko > crash> p test_no_static > test_no_static = $1 = 5 > crash> > > Signed-off-by: Lianbo Jiang<lijiang(a)redhat.com> > --- > Here is the test case: > #include <linux/kernel.h> > #include <linux/module.h> > > int test_no = 0; > static int test_no_static = 0; > > static int test_init(void) > { > test_no += 5; > test_no_static += 5; > printk(KERN_INFO "%d static=%d\n", test_no, test_no_static); > return 0; > } > static void test_exit(void) > > { > test_no += 7; > test_no_static += 7; > printk(KERN_INFO "%d static=%d\n", test_no, test_no_static); > } > module_init(test_init); > module_exit(test_exit); > MODULE_LICENSE("GPL"); > > > gdb-10.2.patch | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/gdb-10.2.patch b/gdb-10.2.patch > index a7018a249118..35388ba03e25 100644 > --- a/gdb-10.2.patch > +++ b/gdb-10.2.patch > @@ -16057,3 +16057,27 @@ exit 0 > m10200-dis.c > m10200-opc.c > m10300-dis.c > +--- gdb-10.2/gdb/minsyms.c.orig > ++++ gdb-10.2/gdb/minsyms.c > +@@ -535,7 +535,9 @@ lookup_minimal_symbol_linkage (const char *name, struct objfile *objf) > + { > + if (strcmp (msymbol->linkage_name (), name) == 0 > + && (MSYMBOL_TYPE (msymbol) == mst_data > +- || MSYMBOL_TYPE (msymbol) == mst_bss)) > ++ || MSYMBOL_TYPE (msymbol) == mst_bss > ++ || MSYMBOL_TYPE (msymbol) == mst_file_bss > ++ || MSYMBOL_TYPE (msymbol) == mst_file_data)) > + return {msymbol, objfile}; > + } > + } > +--- gdb-10.2/gdb/symtab.h.orig > ++++ gdb-10.2/gdb/symtab.h > +@@ -1110,7 +1110,7 @@ struct symbol : public general_symbol_info, public allocate_on_obstack > + is_objfile_owned (1), > + is_argument (0), > + is_inlined (0), > +- maybe_copied (0), > ++ maybe_copied (1),/* The objfile potentially supports copy relocations. */ > + subclass (SYMBOL_NONE) > + { > + /* We can't use an initializer list for members of a base class, and > -- 2.41.0

5 months, 4 weeks

1
0
0 / 0

[Crash-Utility][PATCH] symbols.c: skip non-exist module memory type

by Tao Liu

Not all mod_mem_type will be included for kernel modules. E.g. in the following module case: (gdb) p lm->symtable[0] $1 = (struct syment *) 0x4dcbad0 (gdb) p lm->symtable[1] $2 = (struct syment *) 0x4dcbb70 (gdb) p lm->symtable[2] $3 = (struct syment *) 0x4dcbc10 (gdb) p lm->symtable[3] $4 = (struct syment *) 0x0 (gdb) p lm->symtable[4] $5 = (struct syment *) 0x4dcbcb0 (gdb) p lm->symtable[5] $6 = (struct syment *) 0x4dcbd00 (gdb) p lm->symtable[6] $7 = (struct syment *) 0x0 (gdb) p lm->symtable[7] $8 = (struct syment *) 0x4dcbb48 mod_mem MOD_RO_AFTER_INIT(3) and MOD_INIT_RODATA(6) is not exist, which should be skipped, otherwise a segfault will happen. Fixes: 7750e61fdb2a ("Support module memory layout change on Linux 6.4") Signed-off-by: Tao Liu <ltao(a)redhat.com> Reported-by: Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com> --- symbols.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/symbols.c b/symbols.c index cbc9ed1..27e55c6 100644 --- a/symbols.c +++ b/symbols.c @@ -5580,7 +5580,7 @@ value_search_module_6_4(ulong value, ulong *offset) sp = lm->symtable[t]; sp_end = lm->symend[t]; - if (value < sp->value || value > sp_end->value) + if (!sp || value < sp->value || value > sp_end->value) continue; splast = NULL; -- 2.40.1

5 months, 4 weeks

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Crash-utility April 2024