On Sat, Nov 9, 2024 at 9:14 AM <devel-request@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Date: Fri, 8 Nov 2024 21:13:19 +1300
From: Tao Liu <ltao@xxxxxxxxxx>
Subject: Re: [PATCH] RISCV64: add panic signature to
panic_msg to properly display the PANIC message
To: Austin Kim <austindh.kim@xxxxxxxxx>
Cc: lijiang <lijiang@xxxxxxxxxx>, devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx,
Austin Kim <austindhkim@xxxxxxxxx>, 김동현 <austin.kim@xxxxxxx>
Message-ID:
<CAO7dBbWgemin4FPcSkgQ21dbbqW-S8KeFtNuaH8otOZvNWQVSA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Hi Austin & Lianbo,
On Fri, Nov 8, 2024 at 1:35 AM Austin Kim <austindh.kim@xxxxxxxxx> wrote:
>
> Hello Lianbo,
>
> 2024년 11월 6일 (수) 오후 12:53, lijiang <lijiang@xxxxxxxxxx>님이 작성:
> >
> > Hi, Austin
> > Thank you for the patch.
> >
> > On Fri, Nov 1, 2024 at 5:19 PM <devel-request@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> Date: Tue, 29 Oct 2024 17:32:07 +0900
> >> From: Austin Kim <austindh.kim@xxxxxxxxx>
> >> Subject: [PATCH] RISCV64: add panic signature to
> >> panic_msg to properly display the PANIC message
> >> To: devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> >> Cc: austindh.kim@xxxxxxxxx, austin.kim@xxxxxxx
> >> 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@xxxxxxxxx>
> >> ---
> >> 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);
> > }
With this patch applied, no regression found, I think this one can work.
Thank you for the confirmation, Austin and Tao.
Applied:
Lianbo
Thanks,
Tao Liu
> >
> > found:
> >
> >
> > What do you think? I haven't tested this one, not sure if it can work for you, could you please try it?
>
> Thank you for the positive feedback on the patch and for sharing
> another great idea.
> I tested the patch you suggested, and it worked well on my side.
> Here’s the crash message:
>
> crash> sys | grep PANIC
> PANIC: "Unable to handle kernel access to user memory without
> uaccess routines at virtual address 0000000000000000"
>
> This new patch is useful not only for RISC-V but also for a wider
> range of architectures,
> and it seems like a better approach than modifying panic_msg[].
>
> Best regards,
> Austin Kim
>
> > 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
>
-- Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
