On Tue, Jul 04, 2023 at 06:40:03PM +0200, Peter Zijlstra wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
Among other things ebreak is part of the BUG() macro (although it is also used to programmatically enter kgdb).
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
If that makes kdb unhappy, fix kdb.
The only relationship this problem has to kgdb/kdb is that is was found using the kgdb test suite. However the panic is absolutely nothing to do with kgdb.
I would never normally be so sure regarding the absence of bugs in kgdb but in this case it can be reproduced when kgdb is not enabled in the KConfig which I think puts it in the clear!
Reproduction is simply:
/bin/echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
Above will panic the kernel but, absent options specifically requesting a panic, this should kill the echo process rather than killing the kernel.
Daniel.