On Tue, Jul 04, 2023 at 06:40:03PM +0200, Peter Zijlstra wrote: > On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@xxxxxxxxxx wrote: > > From: Guo Ren <guoren@xxxxxxxxxxxxxxxxx> > > > > 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.
