On Fri, Jun 30, 2023 at 7:16 AM Guo Ren <guoren@xxxxxxxxxx> wrote: > > On Thu, Jun 29, 2023 at 10:02 AM Daniel Thompson > <daniel.thompson@xxxxxxxxxx> wrote: > > > > On Tue, Feb 21, 2023 at 10:30:18PM -0500, guoren@xxxxxxxxxx wrote: > > > From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > > > > This patch converts riscv to use the generic entry infrastructure from > > > kernel/entry/*. The generic entry makes maintainers' work easier and > > > codes more elegant. Here are the changes: > > > > > > - More clear entry.S with handle_exception and ret_from_exception > > > - Get rid of complex custom signal implementation > > > - Move syscall procedure from assembly to C, which is much more > > > readable. > > > - Connect ret_from_fork & ret_from_kernel_thread to generic entry. > > > - Wrap with irqentry_enter/exit and syscall_enter/exit_from_user_mode > > > - Use the standard preemption code instead of custom > > > > > > Suggested-by: Huacai Chen <chenhuacai@xxxxxxxxxx> > > > Reviewed-by: Björn Töpel <bjorn@xxxxxxxxxxxx> > > > Tested-by: Yipeng Zou <zouyipeng@xxxxxxxxxx> > > > Tested-by: Jisheng Zhang <jszhang@xxxxxxxxxx> > > > Signed-off-by: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > Signed-off-by: Guo Ren <guoren@xxxxxxxxxx> > > > Cc: Ben Hutchings <ben@xxxxxxxxxxxxxxx> > > > > Apologies for the late feedback but I've been swamped lately and only > > recently got round to running the full kgdb test suite on the v6.4 > > series. > > > > The kgdb test suite includes a couple of tests that verify that the > > system resumes after breakpointing due to a BUG(): > > https://github.com/daniel-thompson/kgdbtest/blob/master/tests/test_kdb_fault_injection.py#L24-L45 > > > > These tests have regressed on riscv between v6.3 and v6.4 and a bisect > > is pointing at this patch. With these changes in place then, after kdb > > resumes the system, the BUG() message is printed as normal but then > > immediately fails. From the backtrace it looks like the new entry/exit > > code cannot advance past a compiled breakpoint instruction: > > ~~~ > > PANIC: Fatal exception in interrupt > It comes from: > void die(struct pt_regs *regs, ... > { > ... > if (in_interrupt()) > panic("Fatal exception in interrupt"); > ... > > We could add a dump_backtrace to see what happened: > if (in_interrupt()) { > + dump_backtrace(regs, NULL, KERN_DEFAULT); Sorry, it should be: + dump_backtrace(NULL, NULL, KERN_DEFAULT); We need current stack info, not exception context. > panic("Fatal exception in interrupt"); > } > > > > > > > Entering kdb (current=0xff60000001a2a280, pid 104) on processor 1 due to > > NonMask > > able Interrupt @ 0xffffffff800bb3c4 > > [1]kdb> bt > > Stack traceback for pid 104 > > 0xff60000001a2a280 104 92 1 1 R 0xff60000001a2ac50 > > *echo > > CPU: 1 PID: 104 Comm: echo Tainted: G D > > 6.3.0-rc1-00003-gf0bddf50586d #119 > > Hardware name: riscv-virtio,qemu (DT) > > Call Trace: > > [<ffffffff800050dc>] dump_backtrace+0x1c/0x24 > > [<ffffffff808458f8>] show_stack+0x2c/0x38 > > [<ffffffff80851b00>] dump_stack_lvl+0x3c/0x54 > > [<ffffffff80851b2c>] dump_stack+0x14/0x1c > > [<ffffffff800bc4b8>] kdb_dump_stack_on_cpu+0x64/0x66 > > [<ffffffff800c3d2a>] kdb_show_stack+0x82/0x88 > > [<ffffffff800c3dc0>] kdb_bt1+0x90/0xf2 > > [<ffffffff800c4206>] kdb_bt+0x34c/0x384 > > [<ffffffff800c1d28>] kdb_parse+0x27a/0x618 > > [<ffffffff800c2566>] kdb_main_loop+0x3b2/0x8fa > > [<ffffffff800c4c5a>] kdb_stub+0x1ba/0x3a8 > > [<ffffffff800bbba8>] kgdb_cpu_enter+0x342/0x5ba > > [<ffffffff800bc3da>] kgdb_handle_exception+0xe0/0x11a > > [<ffffffff8000810c>] kgdb_riscv_notify+0x86/0xb4 > > [<ffffffff8002f210>] notify_die+0x6a/0xa6 > > [<ffffffff80004db0>] handle_break+0x70/0xe0 > > [<ffffffff80852462>] do_trap_break+0x48/0x5c > > [<ffffffff80003598>] ret_from_exception+0x0/0x64 > > [<ffffffff800bb3c4>] kgdb_compiled_break+0x0/0x14 > > ~~~ > > > > > > Daniel. > > > > -- > Best Regards > Guo Ren -- Best Regards Guo Ren
