public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Guo Ren <guoren@kernel.org>
Cc: arnd@arndb.de, palmer@rivosinc.com, tglx@linutronix.de,
	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, 10 Jul 2023 10:01:52 +0200	[thread overview]
Message-ID: <20230710080152.GA3028865@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJF2gTTc0Gyo=K-0dCW6wu7q=Wq34hgTB69qJ7VSF_KAgKhavA@mail.gmail.com>

On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote:
> On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra <peterz@infradead.org> 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?
> EBREAK is just an instruction of riscv which would rise breakpoint exception.
> 
> 
> >
> > 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.
> When the ebreak happend out of local_irq_disable region, but
> __nmi_enter forces handle_break() into in_interupt() state. So how

And why is that a problem? I think I'm missing something fundamental
here...

> about:
> 
> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> index f910dfccbf5d..69f7043a98b9 100644
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -18,6 +18,7 @@
>  #include <linux/irq.h>
>  #include <linux/kexec.h>
>  #include <linux/entry-common.h>
> +#include <linux/context_tracking.h>
> 
>  #include <asm/asm-prototypes.h>
>  #include <asm/bug.h>
> @@ -285,12 +286,18 @@ asmlinkage __visible __trap_section void
> do_trap_break(struct pt_regs *regs)
>                 handle_break(regs);
> 
>                 irqentry_exit_to_user_mode(regs);
> -       } else {
> +       } else if (in_interrupt()){
>                 irqentry_state_t state = irqentry_nmi_enter(regs);
> 
>                 handle_break(regs);
> 
>                 irqentry_nmi_exit(regs, state);
> +       } else {
> +               enum ctx_state prev_state = exception_enter();
> +
> +               handle_break(regs);
> +
> +               exception_exit(prev_state);
>         }
>  }

That's wrong. If you want to make it conditional, you have to look at
!(regs->status & SR_IE) (that's the interrupt enable flag of the
interrupted context, right?)

When you hit an EBREAK when IRQs were disabled, you must be NMI like.

But making it conditional like this makes it really hard to write a
handler though, it basically must assume it will be NMI contetx (because
it can't know) so there is no point in sometimes not doing NMI context.

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

  reply	other threads:[~2023-07-10  8:02 UTC|newest]

Thread overview: 10+ 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 [this message]
2023-07-16 23:33       ` Guo Ren
2023-07-17 10:45         ` Peter Zijlstra
2023-07-17 16:14           ` Guo Ren

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=20230710080152.GA3028865@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --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=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=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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