All of lore.kernel.org
 help / color / mirror / Atom feed
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.

WARNING: multiple messages have this Message-ID (diff)
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.

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

  parent reply	other threads:[~2026-06-22 11:33 UTC|newest]

Thread overview: 32+ 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-02  2:57 ` guoren
2023-07-03 10:29 ` Daniel Thompson
2023-07-03 10:29   ` Daniel Thompson
2023-07-04  2:44   ` Guo Ren
2023-07-04  2:44     ` Guo Ren
2023-07-04 16:40 ` Peter Zijlstra
2023-07-04 16:40   ` Peter Zijlstra
2023-07-04 17:34   ` Daniel Thompson
2023-07-04 17:34     ` Daniel Thompson
2023-07-09  2:30   ` Guo Ren
2023-07-09  2:30     ` Guo Ren
2023-07-10  8:01     ` Peter Zijlstra
2023-07-10  8:01       ` Peter Zijlstra
2023-07-16 23:33       ` Guo Ren
2023-07-16 23:33         ` Guo Ren
2023-07-17 10:45         ` Peter Zijlstra
2023-07-17 10:45           ` Peter Zijlstra
2023-07-17 16:14           ` Guo Ren
2023-07-17 16:14             ` Guo Ren
2026-06-19 23:54 ` Kees Cook
2026-06-19 23:54   ` Kees Cook
2026-06-21  6:52   ` Guo Ren
2026-06-21  6:52     ` Guo Ren
2026-06-22  8:28     ` Peter Zijlstra
2026-06-22  8:28       ` Peter Zijlstra
2026-06-22 10:25       ` Vivian Wang
2026-06-22 10:25         ` Vivian Wang
2026-06-22 11:17         ` Peter Zijlstra
2026-06-22 11:17           ` Peter Zijlstra
2026-06-22 11:33         ` Thomas Gleixner [this message]
2026-06-22 11:33           ` Thomas Gleixner

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.