crash maintainers update
by HAGIO KAZUHITO(萩尾 一仁)
Hi,
As of today, I'm stepping down as a crash co-maintainer because of a few
reasons, mainly to get time to work on another project. Thank you
everyone very much for helping me for about 4 years!
with respect to makedumpfile, I will continue to maintain it until the
handover is finished at least, so will be around the crash community for
a while :-)
Thanks,
Kazu
11 months, 2 weeks
Re: Crash-utility Digest, Vol 223, Issue 26
by lijiang
Hi, Kazu
On Wed, Apr 24, 2024 at 3:32 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Wed, 24 Apr 2024 07:30:52 +0000
> From: HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
> Subject: [Crash-utility] crash maintainers update
> To: "devel(a)lists.crash-utility.osci.io"
> <devel(a)lists.crash-utility.osci.io>
> Message-ID: <3e3c3942-d48a-4b71-b42d-354a06e0a60f(a)nec.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> As of today, I'm stepping down as a crash co-maintainer because of a few
> reasons, mainly to get time to work on another project. Thank you
> everyone very much for helping me for about 4 years!
>
>
I would be honored to work with you on crash-utility, Kazu. I really
cherish this wonderful time, and learned a lot from you.
There is no doubt that you have proven to be an excellent contributor and
maintainer. And thank you for the contribution to crash-utility.
Anyway, maybe we will still meet you again upstream in the future, this is
not the end but another new journey.
Also please allow me to take this opportunity to thank you all for your
contributions and support.
Thanks
Lianbo
with respect to makedumpfile, I will continue to maintain it until the
> handover is finished at least, so will be around the crash community for
> a while :-)
>
> Thanks,
> Kazu
>
11 months, 2 weeks
[ANNOUNCE] crash-8.0.5 is available
by HAGIO KAZUHITO(萩尾 一仁)
Download from:
https://crash-utility.github.io/
or
https://github.com/crash-utility/crash/releases
The GitHub master branch serves as a development branch that will
contain all patches that are queued for the next release:
$ git clone https://github.com/crash-utility/crash.git
Changelog:
ceacceef7d13 crash-8.0.4 -> crash-8.0.5
eedf12d47584 gdb: fix "p" command to print module variables correctly
7d4daf0c0354 x86_64: Fix "bt" command to handle IRQ exception frames properly
ced754d3f8ce Fix segmentation fault in value_search_module_6_4()
ce47cb8dabb5 x86_64: Fix for "bt" command incorrectly printing "bogus exception frame" warning
5b24e363a898 get vmalloc start address from vmcoreinfo
18bf18cf2e6b arm64: Add support for vmemmap symbol in vmcoreinfo
3f205d1d4af5 LoongArch64: Fixed link errors when build on LOONGARCH64 machine
cc3049044a72 gdb-10.2.patch: Fix duplicated code by re-applying patch
5977936c0a91 Add "log -c" option to display printk caller id
3d60d9d40457 Fix "mount" command failure on Linux 6.8-rc1 and later
e924f6d8a1d2 LoongArch64: Add LoongArch64 architecture support information
c3939d2e1930 LoongArch64: Add "--kaslr" command line option support
0f34aa46cae9 LoongArch64: Add 'irq' command support
be214379cdb9 LoongArch64: Add 'help -r' command support
ab4c69f992ad LoongArch64: Add 'help -m/M' command support
87f031ada9df LoongArch64: Add 'bt' command support
756158045183 LoongArch64: Add 'mach' command support
7b8db357511c LoongArch64: Add 'pte' command support
89ae0e226fa9 LoongArch64: Make the crash tool successfully enter the crash command line
35a2472e7a30 Add LoongArch64 framework code support
28891d112754 symbols: skip the module if the given address is not within its address range
aed1b7d3a064 x86_64: Fix "bt" command not printing stack trace enough
a69496279133 RISCV64: Add per-cpu overflow stacks support
12fbed3280a1 RISCV64: Add per-cpu IRQ stacks support
d86dc6901ce7 RISCV64: Add support for 'bt -e' option
edb2bd52885c arm64: support HW Tag-Based KASAN (MTE) mode
53d2577cef98 x86_64: check bt->bptr before calculate framesize
38435c3acec0 help.c: Remove "kmem -l" help messages
19d3c56c9fca arm64: rewrite the arm64_get_vmcoreinfo_ul to arm64_get_vmcoreinfo
9b69093e623f RISCV64: Fix 'bt' output when no ra on the stack top
5187a0320cc5 RISCV64: Dump NT_PRSTATUS in 'help -n'
d0164e7e480a s390x: uncouple physical and virtual memory spaces
4c78eb4a9199 s390x: fix virtual vs physical address confusion
2e513114e7d7 Fix identity_map_base value dump on S390
c15da0752629 use NR_SWAPCACHE when nr_swapper_spaces isn't available
0c5ef6a4a3a2 symbols: skip load .init.* sections if module was successfully initialized
f2ee6fa6c841 symbols: expand all kernel module symtable if not all expanded previously
582febffa8b3 zram: Fixes for lookup_swap_cache()
d65e5d3eae0d Fix typos in offset_table and missing "help -o" items
38acd02c7fc0 Fix "rd" command for zram data display in Linux 6.2 and later
61c8fdb1d7f7 Mark start of 8.0.5 development phase with version 8.0.4++
Full changelog:
https://crash-utility.github.io/changelog/ChangeLog-8.0.5.txt
or
https://github.com/crash-utility/crash/compare/8.0.4...8.0.5
11 months, 2 weeks
[PATCH] gdb: fix the "p" command incorrectly print the value of a global variable
by Lianbo Jiang
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
11 months, 3 weeks
Re: [PATCH] x86_64: rhel 9.3: "crash" doesn't handle all IRQ exception properly
by Lianbo Jiang
Hi, Aureau
Thank you for the fix.
On 4/5/24 08:38, devel-request(a)lists.crash-utility.osci.io wrote:
> Date: Thu, 4 Apr 2024 14:39:06 +0000
> From: "Aureau, Georges (Kernel Tools ERT)"<georges.aureau(a)hpe.com>
> Subject: [Crash-utility] [PATCH] x86_64: rhel 9.3: "crash" doesn't
> handle all IRQ exception properly.
> To:"devel(a)lists.crash-utility.osci.io"
> <devel(a)lists.crash-utility.osci.io>
> Message-ID: <SJ0PR84MB14821A83D9631672B4F0F9449F3C2(a)SJ0PR84MB1482.NAMP
> RD84.PROD.OUTLOOK.COM>
> Content-Type: text/plain; charset="us-ascii"
>
>
> 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;
Can you help to try the following changes? It could be good to check the
relevant symbol, but I'm not sure if this can work well for you and
cover some corner cases.
diff --git a/x86_64.c b/x86_64.c
index aec82b03b62e..251e224c013b 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -6574,6 +6574,8 @@ x86_64_irq_eframe_link_init(void)
if (symbol_exists("asm_common_interrupt")) {
if (symbol_exists("asm_call_on_stack"))
machdep->machspec->irq_eframe_link = -64;
+ else if (symbol_exists("sysvec_apic_timer_interrupt"))
+ machdep->machspec->irq_eframe_link = -24;
else
machdep->machspec->irq_eframe_link = -32;
return;
Thanks
Lianbo
11 months, 3 weeks
[PATCH] Reflect __{start,end}_init_task kernel symbols rename
by Alexander Gordeev
Kernel commit 8f69cba096b5 ("x86: Rename __{start,end}_init_task to
__{start,end}_init_stack") leads to failure:
crash: invalid count request: 0
Assume both __{start,end}_init_task and __{start,end}_init_stack
symbols could exist for backward compatibility.
Signed-off-by: Alexander Gordeev <agordeev(a)linux.ibm.com>
---
task.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/task.c b/task.c
index ebdb5be..88e1d50 100644
--- a/task.c
+++ b/task.c
@@ -496,10 +496,17 @@ task_init(void)
((len = SIZE(thread_union)) != STACKSIZE())) {
machdep->stacksize = len;
} else if (!VALID_SIZE(thread_union) && !VALID_SIZE(task_union)) {
+ len = 0;
if (kernel_symbol_exists("__start_init_task") &&
kernel_symbol_exists("__end_init_task")) {
len = symbol_value("__end_init_task");
len -= symbol_value("__start_init_task");
+ } else if (kernel_symbol_exists("__start_init_stack") &&
+ kernel_symbol_exists("__end_init_stack")) {
+ len = symbol_value("__end_init_stack");
+ len -= symbol_value("__start_init_stack");
+ }
+ if (len) {
ASSIGN_SIZE(thread_union) = len;
machdep->stacksize = len;
}
--
2.40.1
12 months
[Crash-Utility][PATCH v1 00/12] gdb stack unwinding support for crash utility
by Tao Liu
This patchset is a rebase/merged version of the following 3 patchsets:
1): [PATCH v10 0/5] Improve stack unwind on ppc64 [1]
2): [PATCH 0/5] x86_64 gdb stack unwinding support [2]
3): Clean up on top of one-thread-v2 [3]
A complete description of gdb stack unwinding support for crash can be
found in [1].
This patchset can be divided into the following 2 parts:
1) part1: arch independent, mainly modify on the
crash_target.c/gdb_interface.c files, in preparation of the
gdb side.
2) part2: arch specific part, for implementing ppc64/x86_64/arm64 gdb
stack unwinding support.
=== part 2
arm64: Add gdb stack unwinding support
Fix cpumask_t recursive dependence issue
Parse stack by inactive_stack_frame priorily if the struct is valid
x86_64: Add gdb stack unwinding support
ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg
=== part 1
Stop stack unwinding at non-kernel address
Fix gdb_interface: restore gdb's output streams at end of gdb_interface
Print task pid/command instead of CPU index
Rename get_cpu_reg to get_current_task_reg
Let crash change gdb context
Leave only one gdb thread for crash
Remove 'frame' from prohibited commands list
===
[1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00469.html
[2]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00488.html
[3]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00554.html
Aditya Gupta (3):
Remove 'frame' from prohibited commands list
Fix gdb_interface: restore gdb's output streams at end of
gdb_interface
ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg
Tao Liu (9):
Leave only one gdb thread for crash
Let crash change gdb context
Rename get_cpu_reg to get_current_task_reg
Print task pid/command instead of CPU index
Stop stack unwinding at non-kernel address
x86_64: Add gdb stack unwinding support
Parse stack by inactive_stack_frame priorily if the struct is valid
Fix cpumask_t recursive dependence issue
arm64: Add gdb stack unwinding support
arm64.c | 114 ++++++++++++++++++-
crash_target.c | 47 +++++---
defs.h | 187 ++++++++++++++++++++++++++++++-
gdb-10.2.patch | 79 +++++++++++++
gdb_interface.c | 33 ++----
kernel.c | 61 ++++++++--
ppc64.c | 163 +++++++++++++++++++++++++--
task.c | 30 +++--
tools.c | 8 +-
x86_64.c | 290 +++++++++++++++++++++++++++++++++++++++++++-----
10 files changed, 907 insertions(+), 105 deletions(-)
--
2.40.1
12 months
Re: How to get module symbols working ?
by Tao Liu
Hi Naveen,
On Wed, Apr 3, 2024 at 12:48 PM Naveen Chaudhary
<naveenchaudhary2010(a)hotmail.com> wrote:
>
> 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>
I think this is correct and expected output from crash. The
"_MODULE_INIT_TEXT_START_npdereference" represents the module_init
function null_deref_module_init(). I know you are expecting the same
string as the latter, but the internal is a little different from your
thought:
The "_MODULE_INIT_TEXT_START_npdereference", or "_MODULE_INIT_START_ +
module_name", is created intentionally as a pseudo-symbol in
crash:symbols.c:store_module_symbols_v2(), as I quote it here:
st->ext_module_symtable[mcnt].value = lm->mod_init_module_ptr;
st->ext_module_symtable[mcnt].type = 'm';
st->ext_module_symtable[mcnt].flags |= MODULE_SYMBOL;
sprintf(buf3, "%s%s", "_MODULE_INIT_START_", mod_name);
The value/address of the symbol is mod_init_module_ptr, aka the
module_init function.
I don't have the history background why it is designed like this.
Let's disassemble nfsv4.ko as an example:
$ objdump -S nfsv4.ko
...
Disassembly of section .init.text:
0000000000000000 <init_module>:
static int __init init_nfs_v4(void)
{
0: e8 00 00 00 00 callq 5 <init_module+0x5>
5: 53 push %rbx
err = nfs_dns_resolver_init();
if (err)
goto out;
err = nfs_idmap_init();
6: e8 00 00 00 00 callq b <init_module+0xb>
b: 89 c3 mov %eax,%ebx
if (err)
The function name is taken as init_module instead of init_nfs_v4. So
just by guessing, such a pseudo name is better for identification.
Thanks,
Tao Liu
>
> 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
>
> --
> 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
12 months
