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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJ2PBosSQtSX28Mf@wychelm>
Date:   Thu, 29 Jun 2023 15:02:46 +0100
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     guoren@...nel.org
Cc:     arnd@...db.de, palmer@...osinc.com, tglx@...utronix.de,
        peterz@...radead.org, luto@...nel.org, conor.dooley@...rochip.com,
        heiko@...ech.de, jszhang@...nel.org, lazyparser@...il.com,
        falcon@...ylab.org, chenhuacai@...nel.org, apatel@...tanamicro.com,
        atishp@...shpatra.org, mark.rutland@....com, ben@...adent.org.uk,
        bjorn@...nel.org, palmer@...belt.com, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Guo Ren <guoren@...ux.alibaba.com>,
        Björn Töpel <bjorn@...osinc.com>,
        Yipeng Zou <zouyipeng@...wei.com>,
        Vincent Chen <vincent.chen@...ive.com>
Subject: Re: [PATCH -next V17 4/7] riscv: entry: Convert to generic entry

On Tue, Feb 21, 2023 at 10:30:18PM -0500, guoren@...nel.org wrote:
> From: Guo Ren <guoren@...ux.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@...nel.org>
> Reviewed-by: Björn Töpel <bjorn@...osinc.com>
> Tested-by: Yipeng Zou <zouyipeng@...wei.com>
> Tested-by: Jisheng Zhang <jszhang@...nel.org>
> Signed-off-by: Guo Ren <guoren@...ux.alibaba.com>
> Signed-off-by: Guo Ren <guoren@...nel.org>
> Cc: Ben Hutchings <ben@...adent.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

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.