Messages in this thread | | | Date | Tue, 4 Jul 2023 18:34:51 +0100 | From | Daniel Thompson <> | Subject | Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side |
| |
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.
| |