Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side

[Thomas Gleixner]

On Mon, Jun 22 2026 at 18:25, Vivian Wang wrote:
> On 6/22/26 16:28, Peter Zijlstra wrote:
>> I still don't understand it. This cannot fix anything. Consider:
>>
>>  EBREAK
>>  raw_spin_lock_irq(&your_lock)
>>  EBREAK
>>
>> So now the first 'works', but the second will crash. Additionally,
>> having the EBREAK context differ so dramatically between invocations
>> seems like a very bad deal to me.
>
> To spell it out, the problem that needs fixing is:
>
> -> BUG()
>    -> ebreak instruction
>       -> Breakpoint exception
>          -> do_trap_break()
>             -> irqentry_nmi_enter()
>             [ now in_nmi() / in_interrupt() ]
>             -> report_bug() returns BUG_TRAP_TYPE_BUG
>             -> die()
>                -> make_task_dead()
>                   -> panic() because we're in_interrupt()
>
> As such, currently on riscv all BUG() simply completely panic() the
> entire machine, rather than just killing the one task.
>
> How do you think this should be fixed? Here are some ideas but I'm not
> familiar with generic entry stuff:
>
>   * Should we irqentry_nmi_exit() before calling die() for BUG()?
>   * Should we move the GENERIC_BUG trap instruction to cause illegal
>     instruction exception instead, for which we can write a simpler
>     handler that doesn't need to care about the probe stuff?

Look at how x86 handles UD exceptions.