[PATCH -next V17 4/7] riscv: entry: Convert to generic entry

[Guo Ren]

On Thu, Jun 29, 2023 at 10:02 AM Daniel Thompson
<daniel.thompson at linaro.org> wrote:
>
> On Tue, Feb 21, 2023 at 10:30:18PM -0500, guoren at kernel.org wrote:
> > From: Guo Ren <guoren at linux.alibaba.com>
> >
> > 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 at kernel.org>
> > Reviewed-by: Björn Töpel <bjorn at rivosinc.com>
> > Tested-by: Yipeng Zou <zouyipeng at huawei.com>
> > Tested-by: Jisheng Zhang <jszhang at kernel.org>
> > Signed-off-by: Guo Ren <guoren at linux.alibaba.com>
> > Signed-off-by: Guo Ren <guoren at kernel.org>
> > Cc: Ben Hutchings <ben at decadent.org.uk>
>
> 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);
        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