From: Thomas Gleixner <tglx@linutronix.de>
To: Vivian Wang <wangruikang@iscas.ac.cn>,
Peter Zijlstra <peterz@infradead.org>,
Guo Ren <guoren@kernel.org>
Cc: Kees Cook <kees@kernel.org>,
arnd@arndb.de, palmer@rivosinc.com, luto@kernel.org,
conor.dooley@microchip.com, heiko@sntech.de, jszhang@kernel.org,
lazyparser@gmail.com, falcon@tinylab.org, chenhuacai@kernel.org,
apatel@ventanamicro.com, atishp@atishpatra.org,
mark.rutland@arm.com, bjorn@kernel.org, palmer@dabbelt.com,
bjorn@rivosinc.com, daniel.thompson@linaro.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, stable@vger.kernel.org,
Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [PATCH] riscv: entry: Fixup do_trap_break from kernel side
Date: Mon, 22 Jun 2026 13:33:01 +0200 [thread overview]
Message-ID: <87pl1ilsia.ffs@fw13> (raw)
In-Reply-To: <2f32370b-63c1-4e8a-bf71-d40874b6bebb@iscas.ac.cn>
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.
prev parent reply other threads:[~2026-06-22 11:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-02 2:57 [PATCH] riscv: entry: Fixup do_trap_break from kernel side guoren
2023-07-03 10:29 ` Daniel Thompson
2023-07-04 2:44 ` Guo Ren
2023-07-04 16:40 ` Peter Zijlstra
2023-07-04 17:34 ` Daniel Thompson
2023-07-09 2:30 ` Guo Ren
2023-07-10 8:01 ` Peter Zijlstra
2023-07-16 23:33 ` Guo Ren
2023-07-17 10:45 ` Peter Zijlstra
2023-07-17 16:14 ` Guo Ren
2026-06-19 23:54 ` Kees Cook
2026-06-21 6:52 ` Guo Ren
2026-06-22 8:28 ` Peter Zijlstra
2026-06-22 10:25 ` Vivian Wang
2026-06-22 11:17 ` Peter Zijlstra
2026-06-22 11:33 ` Thomas Gleixner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pl1ilsia.ffs@fw13 \
--to=tglx@linutronix.de \
--cc=apatel@ventanamicro.com \
--cc=arnd@arndb.de \
--cc=atishp@atishpatra.org \
--cc=bjorn@kernel.org \
--cc=bjorn@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=daniel.thompson@linaro.org \
--cc=falcon@tinylab.org \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=heiko@sntech.de \
--cc=jszhang@kernel.org \
--cc=kees@kernel.org \
--cc=lazyparser@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=wangruikang@iscas.ac.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox