Re: [PATCH] RISCV64: add panic signature to panic_msg to properly display the PANIC message
by lijiang
Hi, Austin
Thank you for the patch.
On Fri, Nov 1, 2024 at 5:19 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Tue, 29 Oct 2024 17:32:07 +0900
> From: Austin Kim <austindh.kim(a)gmail.com>
> Subject: [Crash-utility] [PATCH] RISCV64: add panic signature to
> panic_msg to properly display the PANIC message
> To: devel(a)lists.crash-utility.osci.io
> Cc: austindh.kim(a)gmail.com, austin.kim(a)lge.com
> Message-ID: <20241029083207.GA30130@adminpc-PowerEdge-R7525>
> Content-Type: text/plain; charset=us-ascii
>
> Using 'sys' command, we can view the panic message with general system
> information. If we run RISCV64-based vmcore, PANIC message is not properly
> displayed.
>
> The reason is that "Unable to handle kernel" is first printed in the
> kernel log
> when exception occurs in the RISC-V based Linux kernel. The corresponding
> kernel commit is 21733cb518471.
>
> Without the patch:
> crash> sys
> KERNEL: vmlinux [TAINTED]
> DUMPFILE: vmcore
> CPUS: 4
> DATE: Thu Aug 22 16:13:08 KST 2024
> UPTIME: 00:33:25
> LOAD AVERAGE: 0.07, 0.07, 0.02
> TASKS: 385
> NODENAME: starfive
> RELEASE: 6.6.20+
> VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024
> MACHINE: riscv64 (unknown Mhz)
> MEMORY: 4 GB
> PANIC: ""
>
> With the patch:
> crash> sys
> KERNEL: vmlinux [TAINTED]
> DUMPFILE: vmcore
> CPUS: 4
> DATE: Thu Aug 22 16:13:08 KST 2024
> UPTIME: 00:33:25
> LOAD AVERAGE: 0.07, 0.07, 0.02
> TASKS: 385
> NODENAME: starfive
> RELEASE: 6.6.20+
> VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024
> MACHINE: riscv64 (unknown Mhz)
> MEMORY: 4 GB
> PANIC: "Unable to handle kernel access to user memory without
> uaccess routines at virtual address 0000000000000000"
>
> Signed-off-by: Austin Kim <austindh.kim(a)gmail.com>
> ---
> task.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/task.c b/task.c
> index d52ce0b..443f488 100644
> --- a/task.c
> +++ b/task.c
> @@ -6330,6 +6330,7 @@ static const char* panic_msg[] = {
> "[Hardware Error]: ",
> "Bad mode in ",
> "Oops: ",
> + "Unable to handle kernel access ",
>
I would tend to search the panic keywords again as below, which can cover
both riscv64 and aarch64 cases.
diff --git a/task.c b/task.c
index c131cc32067d..9613adebab57 100644
--- a/task.c
+++ b/task.c
@@ -6392,6 +6392,9 @@ get_panicmsg(char *buf)
get_symbol_data("sysrq_pressed", sizeof(int),
&msg_found);
break;
}
+
+ /* try to search panic string with panic keywords*/
+ search_panic_task_by_keywords(buf, &msg_found);
}
found:
What do you think? I haven't tested this one, not sure if it can work for
you, could you please try it?
Tao, can we also do a regression test to double check if there are any
risks?
Thanks
Lianbo
> };
>
> #define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
> --
> 2.17.1
>
5 months
- 3
- 3
Re: [PATCH] Mark --log option as deprecated
by lijiang
On Wed, Nov 6, 2024 at 10:41 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Tue, 5 Nov 2024 15:59:32 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH] Mark --log option as deprecated
> To: devel(a)lists.crash-utility.osci.io
> Cc: Tao Liu <ltao(a)redhat.com>
> Message-ID: <20241105025932.59489-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Since kernel(>=v5.10), a new lockless ringbuffer is introduced. And
> crash commit a5531b24 ("printk: add support for lockless ringbuffer")
> implemented the lockless ringbuffer dumping for cmd_log, this however,
> relies on the existence of kernel debuginfo.
>
> Since there is already a similar function been implemented for
> makedumpfile, aka "makedumpfile --dump-dmesg" to dump dmesg logs with
> only vmcore, there is no need to maintain a similar code in crash
> as well. In addition, this option is not widely used, so just mark
> "--log" option as deprecated for crash.
>
>
This looks good to me.
Applied(with a minor change):
https://github.com/crash-utility/crash/commit/ca74157283dd43d0036ab6b7b93...
Thanks
Lianbo
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> crash.8 | 4 +++-
> help.c | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/crash.8 b/crash.8
> index 0662f92..6abd381 100644
> --- a/crash.8
> +++ b/crash.8
> @@ -333,10 +333,12 @@ or
> .I /proc/kcore
> devices.
> .TP
> -.BI --log \ dumpfile
> +.BI --log \ dumpfile \ (deprecated)
> Dump the contents of the kernel log buffer. A kernel namelist
> argument is not necessary, but the dumpfile must contain the
> VMCOREINFO data taken from the original /proc/vmcore ELF header.
> +Note: this option is deprecated and will no longer work for
> +kernel(>=v5.10), use "makedumpfile --dump-dmesg" instead.
> .TP
> .B --no_kallsyms
> Do not use kallsyms-generated symbol information contained within
> diff --git a/help.c b/help.c
> index e95ac1d..caf52f5 100644
> --- a/help.c
> +++ b/help.c
> @@ -211,10 +211,12 @@ char *program_usage_info[] = {
> " Use device as an alternative device to the /dev/crash, /dev/mem",
> " or /proc/kcore devices.",
> "",
> - " --log dumpfile",
> + " --log dumpfile (deprecated)",
> " Dump the contents of the kernel log buffer. A kernel namelist",
> " argument is not necessary, but the dumpfile must contain the",
> " VMCOREINFO data taken from the original /proc/vmcore ELF
> header.",
> + " Note: this option is deprecated and will no longer work for",
> + " kernel(>=v5.10), use \"makedumpfile --dump-dmesg\" instead.",
> "",
> " --no_kallsyms",
> " Do not use kallsyms-generated symbol information contained
> within",
> --
> 2.47.0
>
5 months
- 1
- 0
[PATCH] arm64: gdb stack unwind append more registers
by Guanyou Chen
Hi Lianbo, Tao
Let gdb fetch_registers include cpu context x19~x28,
This may not mean for already scheduled tasks, but
gdb stack unwind show more args.
Before:
crash> gdb bt
#0 __switch_to (prev=<unavailable>, prev@entry=0xffffff80025f0000,
next=next@entry=<unavailable>) at arch/arm64/kernel/process.c:566
#1 0xffffffc008f820b8 in context_switch (rq=0xffffff81fcf419c0,
prev=0xffffff80025f0000, next=<unavailable>, rf=<optimized out>) at
kernel/sched/core.c:5471
#2 __schedule (sched_mode=<optimized out>, sched_mode@entry=168999904)
at kernel/sched/core.c:6857
#3 0xffffffc008f82514 in schedule () at kernel/sched/core.c:6933
...
After:
crash> gdb bt
#0 __switch_to (prev=prev@entry=0xffffff80025f0000,
next=next@entry=0xffffff80026092c0)
at arch/arm64/kernel/process.c:566
#1 0xffffffc008f820b8 in context_switch (rq=0xffffff81fcf419c0,
prev=0xffffff80025f0000, next=0xffffff80026092c0, rf=<optimized out>) at
kernel/sched/core.c:5471
#2 __schedule (sched_mode=<optimized out>, sched_mode@entry=168999904)
at kernel/sched/core.c:6857
#3 0xffffffc008f82514 in schedule () at kernel/sched/core.c:6933
...
Signed-off-by: Guanyou.Chen <chenguanyou(a)xiaomi.com>
---
arm64.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
defs.h | 20 +++++++++++++++++
symbols.c | 32 ++++++++++++++++++++++-----
3 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/arm64.c b/arm64.c
index 4521b45..86dc341 100644
--- a/arm64.c
+++ b/arm64.c
@@ -2731,6 +2731,9 @@ arm64_stackframe_init(void)
long thread_struct_cpu_context;
long context_sp, context_pc, context_fp;
struct syment *sp1, *sp1n, *sp2, *sp2n, *sp3, *sp3n;
+ long context_x19, context_x20, context_x21, context_x22;
+ long context_x23, context_x24, context_x25, context_x26;
+ long context_x27, context_x28;
STRUCT_SIZE_INIT(note_buf, "note_buf_t");
STRUCT_SIZE_INIT(elf_prstatus, "elf_prstatus");
@@ -2814,6 +2817,16 @@ arm64_stackframe_init(void)
context_sp = MEMBER_OFFSET("cpu_context", "sp");
context_fp = MEMBER_OFFSET("cpu_context", "fp");
context_pc = MEMBER_OFFSET("cpu_context", "pc");
+ context_x19 = MEMBER_OFFSET("cpu_context", "x19");
+ context_x20 = MEMBER_OFFSET("cpu_context", "x20");
+ context_x21 = MEMBER_OFFSET("cpu_context", "x21");
+ context_x22 = MEMBER_OFFSET("cpu_context", "x22");
+ context_x23 = MEMBER_OFFSET("cpu_context", "x23");
+ context_x24 = MEMBER_OFFSET("cpu_context", "x24");
+ context_x25 = MEMBER_OFFSET("cpu_context", "x25");
+ context_x26 = MEMBER_OFFSET("cpu_context", "x26");
+ context_x27 = MEMBER_OFFSET("cpu_context", "x27");
+ context_x28 = MEMBER_OFFSET("cpu_context", "x28");
if (context_sp == INVALID_OFFSET) {
error(INFO, "cannot determine cpu_context.sp offset\n");
return;
@@ -2832,6 +2845,26 @@ arm64_stackframe_init(void)
task_struct_thread + thread_struct_cpu_context + context_fp;
ASSIGN_OFFSET(task_struct_thread_context_pc) =
task_struct_thread + thread_struct_cpu_context + context_pc;
+ ASSIGN_OFFSET(task_struct_thread_context_x19) =
+ task_struct_thread + thread_struct_cpu_context + context_x19;
+ ASSIGN_OFFSET(task_struct_thread_context_x20) =
+ task_struct_thread + thread_struct_cpu_context + context_x20;
+ ASSIGN_OFFSET(task_struct_thread_context_x21) =
+ task_struct_thread + thread_struct_cpu_context + context_x21;
+ ASSIGN_OFFSET(task_struct_thread_context_x22) =
+ task_struct_thread + thread_struct_cpu_context + context_x22;
+ ASSIGN_OFFSET(task_struct_thread_context_x23) =
+ task_struct_thread + thread_struct_cpu_context + context_x23;
+ ASSIGN_OFFSET(task_struct_thread_context_x24) =
+ task_struct_thread + thread_struct_cpu_context + context_x24;
+ ASSIGN_OFFSET(task_struct_thread_context_x25) =
+ task_struct_thread + thread_struct_cpu_context + context_x25;
+ ASSIGN_OFFSET(task_struct_thread_context_x26) =
+ task_struct_thread + thread_struct_cpu_context + context_x26;
+ ASSIGN_OFFSET(task_struct_thread_context_x27) =
+ task_struct_thread + thread_struct_cpu_context + context_x27;
+ ASSIGN_OFFSET(task_struct_thread_context_x28) =
+ task_struct_thread + thread_struct_cpu_context + context_x28;
}
#define KERNEL_MODE (1)
@@ -4256,6 +4289,16 @@ arm64_get_stackframe(struct bt_info *bt, struct
arm64_stackframe *frame)
frame->sp = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_sp));
frame->pc = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_pc));
frame->fp = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_fp));
+ frame->x19 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x19));
+ frame->x20 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x20));
+ frame->x21 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x21));
+ frame->x22 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x22));
+ frame->x23 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x23));
+ frame->x24 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x24));
+ frame->x25 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x25));
+ frame->x26 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x26));
+ frame->x27 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x27));
+ frame->x28 = ULONG(tt->task_struct +
OFFSET(task_struct_thread_context_x28));
return TRUE;
}
@@ -4280,10 +4323,29 @@ arm64_get_stack_frame(struct bt_info *bt, ulong
*pcp, ulong *spp)
ur_bitmap->ur.pc = stackframe.pc;
ur_bitmap->ur.sp = stackframe.sp;
ur_bitmap->ur.regs[29] = stackframe.fp;
+ ur_bitmap->ur.regs[28] = stackframe.x28;
+ ur_bitmap->ur.regs[27] = stackframe.x27;
+ ur_bitmap->ur.regs[26] = stackframe.x26;
+ ur_bitmap->ur.regs[25] = stackframe.x25;
+ ur_bitmap->ur.regs[24] = stackframe.x24;
+ ur_bitmap->ur.regs[23] = stackframe.x23;
+ ur_bitmap->ur.regs[22] = stackframe.x22;
+ ur_bitmap->ur.regs[21] = stackframe.x21;
+ ur_bitmap->ur.regs[20] = stackframe.x20;
+ ur_bitmap->ur.regs[19] = stackframe.x19;
SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, pc));
SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, sp));
- SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0])
- + X29_REGNUM - X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X29_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X28_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X27_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X26_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X25_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X24_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X23_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X22_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X21_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X20_REGNUM -
X0_REGNUM);
+ SET_BIT(ur_bitmap->bitmap, REG_SEQ(arm64_pt_regs, regs[0]) + X19_REGNUM -
X0_REGNUM);
bt->machdep = ur_bitmap;
bt->need_free = TRUE;
}
diff --git a/defs.h b/defs.h
index 0f70827..191b394 100644
--- a/defs.h
+++ b/defs.h
@@ -2010,6 +2010,16 @@ struct offset_table { /* stash of
commonly-used offsets */
long tnt_bit;
long tnt_true;
long tnt_false;
+ long task_struct_thread_context_x19;
+ long task_struct_thread_context_x20;
+ long task_struct_thread_context_x21;
+ long task_struct_thread_context_x22;
+ long task_struct_thread_context_x23;
+ long task_struct_thread_context_x24;
+ long task_struct_thread_context_x25;
+ long task_struct_thread_context_x26;
+ long task_struct_thread_context_x27;
+ long task_struct_thread_context_x28;
long task_struct_thread_context_fp;
long task_struct_thread_context_sp;
long task_struct_thread_context_pc;
@@ -3593,6 +3603,16 @@ struct machine_specific {
};
struct arm64_stackframe {
+ unsigned long x19;
+ unsigned long x20;
+ unsigned long x21;
+ unsigned long x22;
+ unsigned long x23;
+ unsigned long x24;
+ unsigned long x25;
+ unsigned long x26;
+ unsigned long x27;
+ unsigned long x28;
unsigned long fp;
unsigned long sp;
unsigned long pc;
diff --git a/symbols.c b/symbols.c
index f68cf0b..93ddf5a 100644
--- a/symbols.c
+++ b/symbols.c
@@ -9829,12 +9829,32 @@ dump_offset_table(char *spec, ulong makestruct)
OFFSET(task_struct_thread_reg29));
fprintf(fp, " task_struct_thread_reg31: %ld\n",
OFFSET(task_struct_thread_reg31));
- fprintf(fp, " task_struct_thread_context_fp: %ld\n",
- OFFSET(task_struct_thread_context_fp));
- fprintf(fp, " task_struct_thread_context_sp: %ld\n",
- OFFSET(task_struct_thread_context_sp));
- fprintf(fp, " task_struct_thread_context_pc: %ld\n",
- OFFSET(task_struct_thread_context_pc));
+ fprintf(fp, " task_struct_thread_context_x19: %ld\n",
+ OFFSET(task_struct_thread_context_x19));
+ fprintf(fp, " task_struct_thread_context_x20: %ld\n",
+ OFFSET(task_struct_thread_context_x20));
+ fprintf(fp, " task_struct_thread_context_x21: %ld\n",
+ OFFSET(task_struct_thread_context_x21));
+ fprintf(fp, " task_struct_thread_context_x22: %ld\n",
+ OFFSET(task_struct_thread_context_x22));
+ fprintf(fp, " task_struct_thread_context_x23: %ld\n",
+ OFFSET(task_struct_thread_context_x23));
+ fprintf(fp, " task_struct_thread_context_x24: %ld\n",
+ OFFSET(task_struct_thread_context_x24));
+ fprintf(fp, " task_struct_thread_context_x25: %ld\n",
+ OFFSET(task_struct_thread_context_x25));
+ fprintf(fp, " task_struct_thread_context_x26: %ld\n",
+ OFFSET(task_struct_thread_context_x26));
+ fprintf(fp, " task_struct_thread_context_x27: %ld\n",
+ OFFSET(task_struct_thread_context_x27));
+ fprintf(fp, " task_struct_thread_context_x28: %ld\n",
+ OFFSET(task_struct_thread_context_x28));
+ fprintf(fp, " task_struct_thread_context_fp: %ld\n",
+ OFFSET(task_struct_thread_context_fp));
+ fprintf(fp, " task_struct_thread_context_sp: %ld\n",
+ OFFSET(task_struct_thread_context_sp));
+ fprintf(fp, " task_struct_thread_context_pc: %ld\n",
+ OFFSET(task_struct_thread_context_pc));
fprintf(fp, " task_struct_processor: %ld\n",
OFFSET(task_struct_processor));
fprintf(fp, " task_struct_p_pptr: %ld\n",
--
2.34.1
Thanks
Guanyou
5 months
- 2
- 1
Re: [PATCH v7 00/15] gdb stack unwinding support for crash utility
by lijiang
Hi, Tao
Thank you for the update.
The following patch is a regression issue, so I tend to discuss it as a
separate patch.
[PATCH v7 01/15] Fix the regression of cpumask_t for xen hyper
In addition, I found another issue in my tests(on ppc64le), the gdb bt can
display the back trace for the panic task, but when I switch to another
task, the gdb bt can not display the back trace:
crash> gdb bt
#0 0xc0000000002bde04 in crash_setup_regs (newregs=0xc00000003264b858,
oldregs=0x0) at ./arch/powerpc/include/asm/kexec.h:133
#1 0xc0000000002be4f8 in __crash_kexec (regs=0x0) at
kernel/crash_core.c:122
#2 0xc00000000016c254 in panic (fmt=0xc0000000015eef20 "sysrq triggered
crash\n") at kernel/panic.c:373
#3 0xc000000000a708b8 in sysrq_handle_crash (key=<optimized out>) at
drivers/tty/sysrq.c:154
#4 0xc000000000a713d4 in __handle_sysrq (key=key@entry=99 'c',
check_mask=check_mask@entry=false) at drivers/tty/sysrq.c:612
#5 0xc000000000a71e94 in write_sysrq_trigger (file=<optimized out>,
buf=<optimized out>, count=2, ppos=<optimized out>) at
drivers/tty/sysrq.c:1181
#6 0xc00000000073260c in pde_write (pde=0xc00000000af9cc00,
file=<optimized out>, buf=<optimized out>, count=<optimized out>,
ppos=<optimized out>) at fs/proc/inode.c:334
#7 proc_reg_write (file=<optimized out>, buf=<optimized out>,
count=<optimized out>, ppos=<optimized out>) at fs/proc/inode.c:346
#8 0xc00000000063c0e0 in vfs_write (file=0xc0000000092d2900,
buf=0x10012536f60 <error: Cannot access memory at address 0x10012536f60>,
count=2, pos=0xc00000003264bd30) at fs/read_write.c:588
#9 vfs_write (file=0xc0000000092d2900, buf=0x10012536f60 <error: Cannot
access memory at address 0x10012536f60>, count=<optimized out>,
pos=0xc00000003264bd30) at fs/read_write.c:570
#10 0xc00000000063c690 in ksys_write (fd=<optimized out>, buf=0x10012536f60
<error: Cannot access memory at address 0x10012536f60>, count=2) at
fs/read_write.c:643
#11 0xc000000000031a28 in system_call_exception (regs=0xc00000003264be80,
r0=<optimized out>) at arch/powerpc/kernel/syscall.c:153
#12 0xc00000000000d05c in system_call_vectored_common () at
arch/powerpc/kernel/interrupt_64.S:198
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 c000000002bda980 RU 0.0 0 0
[swapper/0]
> 0 0 1 c000000003864c80 RU 0.0 0 0
[swapper/1]
...
8017 923 0 c000000043a20000 IN 0.2 22528 16256
sshd-session
8025 8017 6 c000000032271880 IN 0.1 22784 11840
sshd-session
> 8026 8025 0 c000000043a26600 RU 0.1 9664 6208 bash
...
11645 2 3 c000000032264c80 ID 0.0 0 0
[kworker/u32:2]
11738 6188 2 c00000003811b180 IN 0.1 43520 9408 pickup
12326 2 0 c00000003226b280 ID 0.0 0 0
[kworker/0:1]
13112 6089 2 c00000000c809900 IN 0.0 7232 3456 sleep
Let's take the "pickup" task as an example:
crash> set 11738
PID: 11738
COMMAND: "pickup"
TASK: c00000003811b180 [THREAD_INFO: c00000003811b180]
CPU: 2
STATE: TASK_INTERRUPTIBLE
crash> gdb bt
#0 0xc0000000a7f876a0 in ?? ()
gdb: gdb request failed: bt
crash> set gdb on
gdb: on
gdb> bt
#0 0xc0000000a7f876a0 in ?? ()
gdb>
Anyway, I did the same test on x86 64 and aarch64, it can work well as
expected. Can you help to double check on ppc64 architecture?
X86 64:
crash> set 14599
PID: 14599
COMMAND: "pickup"
TASK: ffff8f57a0d7c180 [THREAD_INFO: ffff8f57a0d7c180]
CPU: 41
STATE: TASK_INTERRUPTIBLE
crash> gdb bt
#0 0xffffffff8b3efe29 in context_switch (rq=0xffff8f6f1f835900,
prev=0xffff8f57a0d7c180, next=0xffff8f5786720000, rf=0xffff9df22fea7b80) at
kernel/sched/core.c:5208
#1 __schedule (sched_mode=sched_mode@entry=0) at kernel/sched/core.c:6549
#2 0xffffffff8b3f0217 in __schedule_loop (sched_mode=<optimized out>) at
kernel/sched/core.c:6626
#3 schedule () at kernel/sched/core.c:6641
#4 0xffffffff8b3f6eef in schedule_hrtimeout_range_clock
(expires=expires@entry=0xffff9df22fea7cb0, delta=<optimized out>,
delta@entry=99999999, mode=mode@entry=HRTIMER_MODE_ABS,
clock_id=clock_id@entry=1) at kernel/time/hrtimer.c:2293
#5 0xffffffff8b3f7003 in schedule_hrtimeout_range
(expires=expires@entry=0xffff9df22fea7cb0,
delta=delta@entry=99999999, mode=mode@entry=HRTIMER_MODE_ABS) at
kernel/time/hrtimer.c:2340
#6 0xffffffff8aae301c in ep_poll (ep=0xffff8f5790d15d40,
events=events@entry=0x7ffea91b6b90, maxevents=maxevents@entry=100,
timeout=timeout@entry=0xffff9df22fea7d58) at fs/eventpoll.c:2062
#7 0xffffffff8aae3138 in do_epoll_wait (epfd=epfd@entry=8,
events=events@entry=0x7ffea91b6b90, maxevents=maxevents@entry=100,
to=0xffff9df22fea7d58) at fs/eventpoll.c:2464
#8 0xffffffff8aae44a1 in __do_sys_epoll_wait (epfd=<optimized out>,
events=0x7ffea91b6b90, maxevents=<optimized out>, timeout=<optimized out>)
at fs/eventpoll.c:2476
#9 __se_sys_epoll_wait (epfd=<optimized out>, events=<optimized out>,
maxevents=<optimized out>, timeout=<optimized out>) at fs/eventpoll.c:2471
#10 __x64_sys_epoll_wait (regs=<optimized out>) at fs/eventpoll.c:2471
#11 0xffffffff8b3e293d in do_syscall_x64 (regs=0xffff9df22fea7f48, nr=232)
at arch/x86/entry/common.c:52
#12 do_syscall_64 (regs=0xffff9df22fea7f48, nr=232) at
arch/x86/entry/common.c:83
#13 0xffffffff8b40012f in entry_SYSCALL_64 () at
arch/x86/entry/entry_64.S:121
crash>
aarch64:
crash> set 9338
PID: 9338
COMMAND: "pickup"
TASK: ffff0000c7b05400 [THREAD_INFO: ffff0000c7b05400]
CPU: 3
STATE: TASK_INTERRUPTIBLE
crash> gdb bt
#0 __switch_to (prev=<unavailable>, prev@entry=0xffff0000c7b05400,
next=next@entry=<unavailable>) at arch/arm64/kernel/process.c:555
#1 0xffffafc5b5ebd744 in context_switch (rq=0xffff00077bbd0ec0,
prev=0xffff0000c7b05400, next=<unavailable>, rf=0xffff80008ac63a60) at
kernel/sched/core.c:5208
#2 __schedule (sched_mode=sched_mode@entry=0) at kernel/sched/core.c:6549
#3 0xffffafc5b5ebdc2c in __schedule_loop (sched_mode=<optimized out>) at
kernel/sched/core.c:6626
#4 schedule () at kernel/sched/core.c:6641
#5 0xffffafc5b5ec6030 in schedule_hrtimeout_range_clock
(expires=expires@entry=0xffff80008ac63be8, delta=delta@entry=99999999,
mode=mode@entry=HRTIMER_MODE_ABS, clock_id=clock_id@entry=1) at
kernel/time/hrtimer.c:2293
#6 0xffffafc5b5ec618c in schedule_hrtimeout_range
(expires=expires@entry=0xffff80008ac63be8,
delta=delta@entry=99999999, mode=mode@entry=HRTIMER_MODE_ABS) at
kernel/time/hrtimer.c:2340
#7 0xffffafc5b545d33c in ep_poll (ep=<unavailable>,
events=events@entry=0xffffde5c3f68,
maxevents=maxevents@entry=100, timeout=timeout@entry=0xffff80008ac63ce0) at
fs/eventpoll.c:2062
#8 0xffffafc5b545d4e4 in do_epoll_wait (epfd=epfd@entry=8,
events=events@entry=0xffffde5c3f68, maxevents=maxevents@entry=100,
to=to@entry=0xffff80008ac63ce0) at fs/eventpoll.c:2464
#9 0xffffafc5b545d534 in do_epoll_pwait (epfd=epfd@entry=8,
events=events@entry=0xffffde5c3f68, maxevents=maxevents@entry=100,
to=to@entry=0xffff80008ac63ce0, sigsetsize=<optimized out>,
sigmask=<optimized out>) at fs/eventpoll.c:2498
#10 0xffffafc5b545e7c8 in do_epoll_pwait (epfd=8, events=0xffffde5c3f68,
maxevents=100, to=0xffff80008ac63ce0, sigmask=<optimized out>,
sigsetsize=<optimized out>) at fs/eventpoll.c:2495
#11 __do_sys_epoll_pwait (epfd=8, events=0xffffde5c3f68, maxevents=100,
timeout=<optimized out>, sigmask=<optimized out>, sigsetsize=<optimized
out>) at fs/eventpoll.c:2511
#12 __se_sys_epoll_pwait (epfd=8, events=281474412330856, maxevents=100,
timeout=<optimized out>, sigmask=<optimized out>, sigsetsize=<optimized
out>) at fs/eventpoll.c:2505
#13 __arm64_sys_epoll_pwait (regs=<optimized out>) at fs/eventpoll.c:2505
#14 0xffffafc5b4fa99bc in __invoke_syscall (regs=0xffff80008ac63eb0,
syscall_fn=<optimized out>) at arch/arm64/kernel/syscall.c:35
#15 invoke_syscall (regs=regs@entry=0xffff80008ac63eb0, scno=<optimized
out>, sc_nr=sc_nr@entry=463, syscall_table=<optimized out>) at
arch/arm64/kernel/syscall.c:49
#16 0xffffafc5b4fa9ac8 in el0_svc_common (sc_nr=463,
syscall_table=<optimized out>, regs=0xffff80008ac63eb0, scno=<optimized
out>) at arch/arm64/kernel/syscall.c:132
#17 do_el0_svc (regs=regs@entry=0xffff80008ac63eb0) at
arch/arm64/kernel/syscall.c:151
#18 0xffffafc5b5eb6fa4 in el0_svc (regs=0xffff80008ac63eb0) at
arch/arm64/kernel/entry-common.c:712
#19 0xffffafc5b5eb74c0 in el0t_64_sync_handler (regs=<optimized out>) at
arch/arm64/kernel/entry-common.c:730
#20 0xffffafc5b4f91634 in el0t_64_sync () at arch/arm64/kernel/entry.S:598
crash>
BTW: other changes are fine to me.
Thanks
Lianbo
On Wed, Sep 4, 2024 at 3:54 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Wed, 4 Sep 2024 19:49:25 +1200
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH v7 00/15] gdb stack unwinding support
> for crash utility
> To: devel(a)lists.crash-utility.osci.io
> Cc: Tao Liu <ltao(a)redhat.com>
> Message-ID: <20240904074940.21331-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 3 parts:
>
> 1) part1: preparations before stack unwinding support, some
> bugs/regressions found when drafting this patchset.
> 2) part2: common part for all CPU archs, mainly dealing with
> crash_target.c/gdb_interface.c files, in order to
> support different archs.
> 3) part3: arch specific, for each ppc64/x86_64/arm64/vmware
> stack unwinding support.
>
> === part 3
> arm64: Add gdb stack unwinding support
> vmware_guestdump: Various format versions support
> x86_64: Add gdb stack unwinding support
> ppc64: correct gdb passthroughs by implementing
> machdep->get_current_task_reg
>
> === part 2
> Conditionally output gdb stack unwinding stop reasons
> Stop stack unwinding at non-kernel address
> 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
>
> === part 1
> Fix gdb_interface: restore gdb's output streams at end of gdb_interface
> x86_64: Fix invalid input "=>" for bt command
> Fix cpumask_t recursive dependence issue
> Fix the regression of cpumask_t for xen hyper
> ===
>
> v7 -> v6:
> 1) Reorganise the patchset, re-divided them into 3 part against the
> previous 2 parts.
> 2) Re-dealed with the cpumask_t part, which solved the comment No.4
> pointed out by lianbo in [4].
> 3) Add conditional output for the failing message of gdb stack unwinding.
> see [PATCH 11/15] Conditionally output gdb stack unwinding stop reasons
> 4) Redraft the commit messages, updated some outdated info.
> 5) Merged "Let crash change gdb context" and "set_context(): check if
> context is already current" into one.
>
> [4]:
> https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01067.html
>
> v6 -> v5:
> 1) Refactor patch 4 & 9, which changed the function signature of struct
> get_cpu_reg/get_current_task_reg, and let each patch compile with no
> error when added on.
> 2) Rebased the patchset on top of latest upstream:
> ("79b93ecb2e72ec Fix a "Bus error" issue caused by 'crash --osrelease'
> or
> crash loading")
>
> v5 -> v4:
> 1) Plenty of code refactoring based on Lianbo's comments on v4.
> 2) Removed the magic number when dealing with regs bitmap, see [6].
> 3) Rebased the patchset on top of latest upstream:
> ("1c6da3eaff8207 arm64: Fix bt command show wrong stacktrace on ramdump
> source")
>
> v4 -> v3:
> Fixed the author issue in [PATCH v3 06/16] Fix gdb_interface: restore gdb's
> output streams at end of gdb_interface.
>
> v3 -> v2:
> 1) Updated CC list as pointed out in [4]
> 2) Compiling issues as in [5]
>
> v2 -> v1:
> 1) Added the patch: x86_64: Fix invalid input "=>" for bt command,
> thanks for Kazu's testing.
> 2) Modify the patch: x86_64: Add gdb stack unwinding support, added the
> pcp_save, spp_save and sp, for restoring the value in match of the
> original
> code logic.
>
> [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
> [4]:
> https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00681.html
> [5]:
> https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00715.html
> [6]:
> https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00819.html
>
> Aditya Gupta (3):
> Fix gdb_interface: restore gdb's output streams at end of
> gdb_interface
> Remove 'frame' from prohibited commands list
> ppc64: correct gdb passthroughs by implementing
> machdep->get_current_task_reg
>
> Alexey Makhalov (1):
> vmware_guestdump: Various format versions support
>
> Tao Liu (11):
> Fix the regression of cpumask_t for xen hyper
> Fix cpumask_t recursive dependence issue
> x86_64: Fix invalid input "=>" for bt command
> 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
> Conditionally output gdb stack unwinding stop reasons
> x86_64: Add gdb stack unwinding support
> arm64: Add gdb stack unwinding support
>
> arm64.c | 120 +++++++++++++++--
> crash_target.c | 71 ++++++----
> defs.h | 194 ++++++++++++++++++++++++++-
> gdb-10.2.patch | 96 ++++++++++++++
> gdb_interface.c | 39 ++----
> kernel.c | 63 +++++++--
> ppc64.c | 174 +++++++++++++++++++++++-
> symbols.c | 15 +++
> task.c | 34 +++--
> tools.c | 16 ++-
> unwind_x86_64.h | 4 -
> vmware_guestdump.c | 321 +++++++++++++++++++++++++++++++-------------
> x86_64.c | 323 ++++++++++++++++++++++++++++++++++++++++-----
> 13 files changed, 1247 insertions(+), 223 deletions(-)
>
> --
> 2.40.1
>
5 months
- 4
- 9
[PATCH] Mark --log option as deprecated
by Tao Liu
Since kernel(>=v5.10), a new lockless ringbuffer is introduced. And
crash commit a5531b24 ("printk: add support for lockless ringbuffer")
implemented the lockless ringbuffer dumping for cmd_log, this however,
relies on the existence of kernel debuginfo.
Since there is already a similar function been implemented for
makedumpfile, aka "makedumpfile --dump-dmesg" to dump dmesg logs with
only vmcore, there is no need to maintain a similar code in crash
as well. In addition, this option is not widely used, so just mark
"--log" option as deprecated for crash.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
crash.8 | 4 +++-
help.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/crash.8 b/crash.8
index 0662f92..6abd381 100644
--- a/crash.8
+++ b/crash.8
@@ -333,10 +333,12 @@ or
.I /proc/kcore
devices.
.TP
-.BI --log \ dumpfile
+.BI --log \ dumpfile \ (deprecated)
Dump the contents of the kernel log buffer. A kernel namelist
argument is not necessary, but the dumpfile must contain the
VMCOREINFO data taken from the original /proc/vmcore ELF header.
+Note: this option is deprecated and will no longer work for
+kernel(>=v5.10), use "makedumpfile --dump-dmesg" instead.
.TP
.B --no_kallsyms
Do not use kallsyms-generated symbol information contained within
diff --git a/help.c b/help.c
index e95ac1d..caf52f5 100644
--- a/help.c
+++ b/help.c
@@ -211,10 +211,12 @@ char *program_usage_info[] = {
" Use device as an alternative device to the /dev/crash, /dev/mem",
" or /proc/kcore devices.",
"",
- " --log dumpfile",
+ " --log dumpfile (deprecated)",
" Dump the contents of the kernel log buffer. A kernel namelist",
" argument is not necessary, but the dumpfile must contain the",
" VMCOREINFO data taken from the original /proc/vmcore ELF header.",
+ " Note: this option is deprecated and will no longer work for",
+ " kernel(>=v5.10), use \"makedumpfile --dump-dmesg\" instead.",
"",
" --no_kallsyms",
" Do not use kallsyms-generated symbol information contained within",
--
2.47.0
5 months
- 1
- 0