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
>
7 hours, 41 minutes
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
>
1 day, 8 hours
[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
1 day, 10 hours
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
>
1 day, 14 hours
[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
3 days, 12 hours
[PATCH] remove offline status check for CPU register map
by Guanyou Chen
Hi Lianbo, Tao
Remove offline status check, We can query the registers of
each CPU at any time and obtain their stack.
CPU 0: [OFFLINE]
X0: 0000000000000000 X1: 0000000000000000 X2: 0000000000000000
X3: 000000000003fcbc X4: 0000000000000001 X5: 0000000000000000
X6: 0000000000000000 X7: 0000000000000000 X8: 00000000ffffffff
X9: ffffffc009e6ae48 X10: ffffffc009e6ae20 X11: 0000000000000000
X12: 0000000000000002 X13: 0000000000000004 X14: 0000000000000000
X15: 0000000000004000 X16: 00000000f90f05f6 X17: 00000000f90f05f6
X18: 0000000000000000 X19: 0000000000000002 X20: ffffffc009e3b008
X21: ffffffc00a01d020 X22: ffffffc009f798f0 X23: 0000000060001000
X24: 0000000000000000 X25: 0000000000000000 X26: 0000000000000000
X27: 0000000000000000 X28: ffffff8111eecb00 X29: ffffffc008003f50
LR: ffffffc00802df88 SP: ffffffc008003f40 PC: ffffffc00802df94
PSTATE: 024003c5 FPVALID: 00000000
crash> bt -c 0
PID: 1842 TASK: ffffff8111eecb00 CPU: 0 COMMAND: "android.bg"
00 [ffffffc008003f50] ipi_handler at ffffffc00802df90
01 [ffffffc008003f90] handle_percpu_devid_irq at ffffffc008146f50
02 [ffffffc008003fd0] generic_handle_domain_irq at ffffffc00813f484
03 [ffffffc008003fe0] gic_handle_irq at ffffffc008010140
--- <IRQ stack> ---
04 [ffffffc019c3be20] call_on_irq_stack at ffffffc008016ed4
05 [ffffffc019c3be40] do_interrupt_handler at ffffffc008019cb4
06 [ffffffc019c3be60] el0_interrupt at ffffffc008f7b848
07 [ffffffc019c3be90] __el0_irq_handler_common at ffffffc008f7b368
08 [ffffffc019c3bea0] el0t_64_irq_handler at ffffffc008f7b344
09 [ffffffc019c3bfe0] el0t_64_irq at ffffffc008011720
PC: 0000000072415108 LR: 00000000724150d0 SP: 0000007691d2bfa0
X29: 00000000734f60e0 X28: 000000001a2fa678 X27: 0000000000000063
X26: 000000001a2fa678 X25: 000000001a2fa678 X24: 000000001a7bb718
X23: 000000001a7ba198 X22: 000000001a7ba190 X21: b4000076f9a828c8
X20: 0000000000000000 X19: b4000076f9a82800 X18: 000000768d68a000
X17: 00000000708f89f8 X16: 00000000000000f0 X15: 0000000000000000
X14: 0000007691d2bca0 X13: 0000000080100000 X12: 0000000000000000
X11: 0000000000000000 X10: 0000000000000000 X9: 9636716211228cd4
X8: 9636716211228cd4 X7: 0000000000000010 X6: 000000001a7bb728
X5: 0000000070845200 X4: 0000000018a40d38 X3: 00000000707e8f98
X2: 000000001a2fa678 X1: 000000001a7ba198 X0: 0000000070847aa8
ORIG_X0: 00000000ffffff9c SYSCALLNO: ffffffff PSTATE: 60001000
Signed-off-by: Guanyou.Chen <chenguanyou(a)xiaomi.com>
---
netdump.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/netdump.c b/netdump.c
index 435793b..455f90e 100644
--- a/netdump.c
+++ b/netdump.c
@@ -101,7 +101,7 @@ map_cpus_to_prstatus(void)
nrcpus = (kt->kernel_NR_CPUS ? kt->kernel_NR_CPUS : NR_CPUS);
for (i = 0; i < nrcpus; i++) {
- if (in_cpu_map(ONLINE_MAP, i) && machdep->is_cpu_prstatus_valid(i))
{
+ if (machdep->is_cpu_prstatus_valid(i)) {
nd->nt_prstatus_percpu[i] = nt_ptr[i];
nd->num_prstatus_notes =
MAX(nd->num_prstatus_notes, i+1);
@@ -2998,15 +2998,10 @@ dump_registers_for_elf_dumpfiles(void)
return;
}
- for (c = 0; c < kt->cpus; c++) {
- if (check_offline_cpu(c)) {
- fprintf(fp, "%sCPU %d: [OFFLINE]\n", c ? "\n" : "", c);
- continue;
- }
-
- fprintf(fp, "%sCPU %d:\n", c ? "\n" : "", c);
- display_regs_from_elf_notes(c, fp);
- }
+ for (c = 0; c < kt->cpus; c++) {
+ fprintf(fp, "%sCPU %d: %s\n", c ? "\n" : "", c,
check_offline_cpu(c) ? "[OFFLINE]" : "[ONLINE]");
+ display_regs_from_elf_notes(c, fp);
+ }
}
struct x86_64_user_regs_struct {
--
2.34.1
Guanyou.
Thanks.
1 week
[PATCH] bugfix command "help -r" segv fault
by Guanyou Chen
Hi Lianbo, Tao
When the ELF Note does not contain CPU registers,
attempting to retrieve online CPU registers will cause a crash.
After:
CPU 6:
help: registers not collected for cpu 6
...
Signed-off-by: Guanyou.Chen <chenguanyou(a)xiaomi.com>
---
netdump.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/netdump.c b/netdump.c
index 8ea5159..435793b 100644
--- a/netdump.c
+++ b/netdump.c
@@ -2780,6 +2780,10 @@ display_regs_from_elf_notes(int cpu, FILE *ofp)
nd->nt_prstatus_percpu[cpu];
else
note64 = (Elf64_Nhdr *)nd->nt_prstatus;
+ if (!note64) {
+ error(INFO, "registers not collected for cpu %d\n", cpu);
+ return;
+ }
len = sizeof(Elf64_Nhdr);
len = roundup(len + note64->n_namesz, 4);
len = roundup(len + note64->n_descsz, 4);
@@ -2820,6 +2824,10 @@ display_regs_from_elf_notes(int cpu, FILE *ofp)
nd->nt_prstatus_percpu[cpu];
else
note32 = (Elf32_Nhdr *)nd->nt_prstatus;
+ if (!note32) {
+ error(INFO, "registers not collected for cpu %d\n", cpu);
+ return;
+ }
len = sizeof(Elf32_Nhdr);
len = roundup(len + note32->n_namesz, 4);
len = roundup(len + note32->n_descsz, 4);
@@ -2857,6 +2865,10 @@ display_regs_from_elf_notes(int cpu, FILE *ofp)
else
note64 = (Elf64_Nhdr *)nd->nt_prstatus;
+ if (!note64) {
+ error(INFO, "registers not collected for cpu %d\n", cpu);
+ return;
+ }
prs = (struct ppc64_elf_prstatus *)
((char *)note64 + sizeof(Elf64_Nhdr) + note64->n_namesz);
prs = (struct ppc64_elf_prstatus *)roundup((ulong)prs, 4);
@@ -2903,6 +2915,10 @@ display_regs_from_elf_notes(int cpu, FILE *ofp)
nd->nt_prstatus_percpu[cpu];
else
note64 = (Elf64_Nhdr *)nd->nt_prstatus;
+ if (!note64) {
+ error(INFO, "registers not collected for cpu %d\n", cpu);
+ return;
+ }
len = sizeof(Elf64_Nhdr);
len = roundup(len + note64->n_namesz, 4);
len = roundup(len + note64->n_descsz, 4);
--
2.34.1
Guanyou.
Thanks
1 week
[PATCH] bugfix map cpus register
by Guanyou Chen
Hi Lianbo, Tao
When CPUs are in an offline state, it can lead to mapping errors.
We need to map them to the correct positions one by one.
Before:
n_namesz: 5 ("CPU2")
n_descsz: 392
n_type: 1 (NT_PRSTATUS)
si.signo: 0 si.code: 0 si.errno: 0
cursig: 0 sigpend: 0 sighold: 0
pid: 3 ppid: 0 pgrp: 0 sid:0
utime: 0.000000 stime: 0.000000
cutime: 0.000000 cstime: 0.000000
X0: ffffffc000fc8818 X1: 0000000000000000 X2:
ffffffc000fc84c8
X3: 0000000000000000 X4: ffffffc0405e37bf X5:
ffffffc00a07372f
X6: 322e34323320205b X7: 545b5d3539383334 X8:
ffffffc000fc2f0c
X9: 89fece0a9ef8cb00 X10: c0000001001f75f4 X11:
00000001001f75f4
X12: 0000000000000003 X13: 00000000000005f4 X14:
ffffffc009eb1210
X15: 0000000000000004 X16: 000000002a4cec24 X17:
000000002a4cec24
X18: ffffffc009e7d140 X19: ffffffc00a04c670 X20:
0000000000000000
X21: 0000000000000000 X22: ffffff8027f22280 X23:
0000000000000009
X24: 0000000000000007 X25: ffffffc009f839c0 X26:
ffffffc0090f87f8
X27: 0000000000000000 X28: ffffff80454f3840 X29:
ffffffc0405e3b60
LR: ffffffc0080e57fc SP: ffffffc0405e3b60 PC:
ffffffc000fc2f84
CPU 0: [OFFLINE]
CPU 1: [OFFLINE]
CPU 2:
X0: 0000000000000000 X1: 0000000000000000 X2: 0000000000000000
X3: 000000000003fcbc X4: 0000000000000001 X5: 0000000000000000
X6: 0000000000000000 X7: 0000000000000000 X8: 00000000ffffffff
X9: ffffffc009e6ae48 X10: ffffffc009e6ae20 X11: 0000000000000000
X12: 0000000000000002 X13: 0000000000000004 X14: 0000000000000000
X15: 0000000000004000 X16: 00000000f90f05f6 X17: 00000000f90f05f6
X18: 0000000000000000 X19: 0000000000000002 X20: ffffffc009e3b008
X21: ffffffc00a01d020 X22: ffffffc009f798f0 X23: 0000000060001000
X24: 0000000000000000 X25: 0000000000000000 X26: 0000000000000000
X27: 0000000000000000 X28: ffffff8111eecb00 X29: ffffffc008003f50
LR: ffffffc00802df88 SP: ffffffc008003f40 PC: ffffffc00802df94
PSTATE: 024003c5 FPVALID: 00000000
After:
CPU 2:
X0: ffffffc000fc8818 X1: 0000000000000000 X2: ffffffc000fc84c8
X3: 0000000000000000 X4: ffffffc0405e37bf X5: ffffffc00a07372f
X6: 322e34323320205b X7: 545b5d3539383334 X8: ffffffc000fc2f0c
X9: 89fece0a9ef8cb00 X10: c0000001001f75f4 X11: 00000001001f75f4
X12: 0000000000000003 X13: 00000000000005f4 X14: ffffffc009eb1210
X15: 0000000000000004 X16: 000000002a4cec24 X17: 000000002a4cec24
X18: ffffffc009e7d140 X19: ffffffc00a04c670 X20: 0000000000000000
X21: 0000000000000000 X22: ffffff8027f22280 X23: 0000000000000009
X24: 0000000000000007 X25: ffffffc009f839c0 X26: ffffffc0090f87f8
X27: 0000000000000000 X28: ffffff80454f3840 X29: ffffffc0405e3b60
LR: ffffffc0080e57fc SP: ffffffc0405e3b60 PC: ffffffc000fc2f84
PSTATE: 600000c5 FPVALID: 00000000
crash> bt
PID: 15959 TASK: ffffff80454f3840 CPU: 2 COMMAND: "AnrConsumer"
[ffffffc0405e3b60] ipanic at ffffffc000fc2f80 [mrdump]
[ffffffc0405e3b70] atomic_notifier_call_chain at ffffffc0080e57f8
[ffffffc0405e3c30] panic at ffffffc008f734d0
[ffffffc0405e3c80] sysrq_handle_crash at ffffffc0087f3c18
[ffffffc0405e3c90] __handle_sysrq at ffffffc0087f3798
[ffffffc0405e3ce0] write_sysrq_trigger at ffffffc0087f49c0
[ffffffc0405e3d00] proc_reg_write at ffffffc00842e4b8
[ffffffc0405e3d80] vfs_write at ffffffc008381eb4
[ffffffc0405e3dd0] ksys_write at ffffffc008382200
[ffffffc0405e3e10] __arm64_sys_write at ffffffc00838228c
[ffffffc0405e3e20] invoke_syscall at ffffffc00802efe0
[ffffffc0405e3e40] el0_svc_common at ffffffc00802eef4
[ffffffc0405e3e70] do_el0_svc at ffffffc00802ede8
[ffffffc0405e3e80] el0_svc at ffffffc008f7a7d0
[ffffffc0405e3ea0] el0t_64_sync_handler at ffffffc008f7a758
[ffffffc0405e3fe0] el0t_64_sync at ffffffc00801157c
PC: 00000077c798ca28 LR: 00000077a82e19f4 SP: 000000761c517af0
X29: 000000761c517b00 X28: 000000761c517db8 X27: 000000761c517c90
X26: 000000761c517c98 X25: 000000761c517bf9 X24: 000000761c519000
X23: 000000761c517be1 X22: 0000000000000001 X21: 00000000000003e3
X20: 000000761c517c11 X19: 000000761c517bf8 X18: 0000007568224000
X17: 00000077c798ca20 X16: 00000077c79b2ae0 X15: b4000077202cc480
X14: 0000000000000000 X13: 000000761c517a70 X12: ffffff80ffffffd0
X11: 000000761c517a40 X10: 0000000000000001 X9: 0000000000000000
X8: 0000000000000040 X7: 7f7f7f7f7f7f7f7f X6: 0000000000000010
X5: 000000761c517c0c X4: ffffffffffffffff X3: ffffffffffffffff
X2: 0000000000000001 X1: 000000761c517c11 X0: 00000000000003e3
ORIG_X0: 00000000000003e3 SYSCALLNO: 40 PSTATE: 00001000
Signed-off-by: Guanyou.Chen <chenguanyou(a)xiaomi.com>
---
netdump.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/netdump.c b/netdump.c
index b4e2a5c..8ea5159 100644
--- a/netdump.c
+++ b/netdump.c
@@ -75,7 +75,7 @@ void
map_cpus_to_prstatus(void)
{
void **nt_ptr;
- int online, i, j, nrcpus;
+ int online, i, nrcpus;
size_t size;
if (pc->flags2 & QEMU_MEM_DUMP_ELF) /* notes exist for all cpus */
@@ -100,9 +100,9 @@ map_cpus_to_prstatus(void)
*/
nrcpus = (kt->kernel_NR_CPUS ? kt->kernel_NR_CPUS : NR_CPUS);
- for (i = 0, j = 0; i < nrcpus; i++) {
+ for (i = 0; i < nrcpus; i++) {
if (in_cpu_map(ONLINE_MAP, i) && machdep->is_cpu_prstatus_valid(i))
{
- nd->nt_prstatus_percpu[i] = nt_ptr[j++];
+ nd->nt_prstatus_percpu[i] = nt_ptr[i];
nd->num_prstatus_notes =
MAX(nd->num_prstatus_notes, i+1);
}
--
2.34.1
Guanyou.
Thanks.
1 week