[PATCH RFC] riscv: Do not handle break traps from kernel as nmi

Alexandre Ghiti posted 1 patch 4 weeks, 1 day ago
arch/riscv/kernel/traps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH RFC] riscv: Do not handle break traps from kernel as nmi
Posted by Alexandre Ghiti 4 weeks, 1 day ago
kprobe has been broken on riscv for quite some time. There is an attempt
[1] to fix that which actually works. This patch works because it enables
ARCH_HAVE_NMI_SAFE_CMPXCHG and that makes the ring buffer allocation
succeed when handling a kprobe because we handle *all* kprobes in nmi
context. We do so because Peter advised us to treat all kernel traps as
nmi [2].

But that does not seem right for kprobe handling, so instead, treat
break traps from kernel as non-nmi.

Link: https://lore.kernel.org/linux-riscv/20250711090443.1688404-1-pulehui@huaweicloud.com/ [1]
Link: https://lore.kernel.org/linux-riscv/20250422094419.GC14170@noisy.programming.kicks-ass.net/ [2]
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
This is clearly an RFC and this is likely not the right way to go, it is
just a way to trigger a discussion about if handling kprobes in an nmi 
context is the right way or not.
---
 arch/riscv/kernel/traps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 80230de167def3c33db5bc190347ec5f87dbb6e3..90f36bb9b12d4ba0db0f084f87899156e3c7dc6f 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -315,11 +315,11 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
 		local_irq_disable();
 		irqentry_exit_to_user_mode(regs);
 	} else {
-		irqentry_state_t state = irqentry_nmi_enter(regs);
+		irqentry_state_t state = irqentry_enter(regs);
 
 		handle_break(regs);
 
-		irqentry_nmi_exit(regs, state);
+		irqentry_exit(regs, state);
 	}
 }
 

---
base-commit: ae9a687664d965b13eeab276111b2f97dd02e090
change-id: 20250903-dev-alex-break_nmi_v1-57c5321f3e80

Best regards,
-- 
Alexandre Ghiti <alexghiti@rivosinc.com>
Re: [PATCH RFC] riscv: Do not handle break traps from kernel as nmi
Posted by Peter Zijlstra 4 weeks, 1 day ago
On Wed, Sep 03, 2025 at 07:54:29PM +0000, Alexandre Ghiti wrote:
> kprobe has been broken on riscv for quite some time. There is an attempt
> [1] to fix that which actually works. This patch works because it enables
> ARCH_HAVE_NMI_SAFE_CMPXCHG and that makes the ring buffer allocation
> succeed when handling a kprobe because we handle *all* kprobes in nmi
> context. We do so because Peter advised us to treat all kernel traps as
> nmi [2].
> 
> But that does not seem right for kprobe handling, so instead, treat
> break traps from kernel as non-nmi.

You can put a kprobe inside: local_irq_disable(), no? Inside any random
spinlock region in fact. How is the probe then not NMI like?
Re: [PATCH RFC] riscv: Do not handle break traps from kernel as nmi
Posted by Alexandre Ghiti 4 weeks ago
Hi Peter,

On 9/3/25 22:28, Peter Zijlstra wrote:
> On Wed, Sep 03, 2025 at 07:54:29PM +0000, Alexandre Ghiti wrote:
>> kprobe has been broken on riscv for quite some time. There is an attempt
>> [1] to fix that which actually works. This patch works because it enables
>> ARCH_HAVE_NMI_SAFE_CMPXCHG and that makes the ring buffer allocation
>> succeed when handling a kprobe because we handle *all* kprobes in nmi
>> context. We do so because Peter advised us to treat all kernel traps as
>> nmi [2].
>>
>> But that does not seem right for kprobe handling, so instead, treat
>> break traps from kernel as non-nmi.
> You can put a kprobe inside: local_irq_disable(), no? Inside any random
> spinlock region in fact. How is the probe then not NMI like?


Yes yes, in that case that will be NMI-like, sorry this patch is coarse 
grain. The ideal solution would be to re-enable the interrupts if they 
were enabled at the moment of the trap. In that case, would that make 
sense to you?

Thanks,

Alex


>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv