All of lore.kernel.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, palmer@dabbelt.com,
	paul.walmsley@sifive.com, mark.rutland@arm.com,
	zouyipeng@huawei.com, bigeasy@linutronix.de,
	David.Laight@aculab.com, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [PATCH V5 07/11] riscv: convert to generic entry
Date: Tue, 20 Sep 2022 09:22:50 +0200	[thread overview]
Message-ID: <YylqSsL6bdhIOMte@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJF2gTRdkmemEWsDYhVXb8KD0PS6b1VAPu_MfeZ+Rmf2qEGa6Q@mail.gmail.com>

On Tue, Sep 20, 2022 at 02:36:33PM +0800, Guo Ren wrote:
> On Mon, Sep 19, 2022 at 9:34 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Sun, Sep 18, 2022 at 11:52:42AM -0400, guoren@kernel.org wrote:
> >
> > > @@ -123,18 +126,22 @@ int handle_misaligned_store(struct pt_regs *regs);
> > >
> > >  asmlinkage void __trap_section do_trap_load_misaligned(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > >       if (!handle_misaligned_load(regs))
> > >               return;
> > >       do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> > >                     "Oops - load address misaligned");
> > > +     irqentry_exit(regs, state);
> > >  }
> > >
> > >  asmlinkage void __trap_section do_trap_store_misaligned(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > >       if (!handle_misaligned_store(regs))
> > >               return;
> > >       do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> > >                     "Oops - store (or AMO) address misaligned");
> > > +     irqentry_exit(regs, state);
> > >  }
> > >  #endif
> > >  DO_ERROR_INFO(do_trap_store_fault,
> > > @@ -158,6 +165,8 @@ static inline unsigned long get_break_insn_length(unsigned long pc)
> > >
> > >  asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > > +
> > >  #ifdef CONFIG_KPROBES
> > >       if (kprobe_single_step_handler(regs))
> > >               return;
> >
> > FWIW; on x86 I've classified many of the 'from-kernel' traps as
> > NMI-like, since those traps can happen from any context, including with
> > IRQs disabled.
> The do_trap_break is for ebreak instruction, not NMI. RISC-V NMI has
> separate CSR. ref:
> 
> This proposal adds support for resumable non-maskable interrupts
> (RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`,
> `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
> and a new instruction to resume from the RNMI handler.

Yes, but that's not what I'm saying. I'm saying I've classified
'from-kernel' traps as NMI-like.

Consider:

	raw_spin_lock_irq(&foo);
	...
	<trap>

Then you want the trap to behave as if it were an NMI; that is abide by
the rules of NMI (strictly wait-free code).

So yes, they are not NMI, but they nest just like it, so we want the
handlers to abide by the same rules.

Does that make sense?

> >
> > The basic shape of the trap handlers looks a little like:
> >
> >         if (user_mode(regs)) {
> If nmi comes from user_mode, why we using
> irqenrty_enter/exit_from/to_user_mode instead of
> irqentry_nmi_enter/exit?

s/nmi/trap/ because the 'from-user' trap never nests inside kernel code.

Additionally, many 'from-user' traps want to do 'silly' things like send
signals, which is something that requires scheduling.

They're fundamentally different from 'from-kernel' traps, which per the
above, nest most dangerously.

> >                 irqenrty_enter_from_user_mode(regs);
> >                 do_user_trap();
> >                 irqentry_exit_to_user_mode(regs);
> >         } else {
> >                 irqentry_state_t state = irqentry_nmi_enter(regs);
> >                 do_kernel_trap();
> >                 irqentry_nmi_exit(regs, state);
> >         }
> >
> > Not saying you have to match Risc-V in this patch-set, just something to
> > consider.
> I think the shape of the riscv NMI handler looks a little like this:
> 
> asmlinkage __visible __trap_section void do_trap_nmi(struct pt_regs *regs)
> {
>                  irqentry_state_t state = irqentry_nmi_enter(regs);
>                  do_nmi_trap();
>                  irqentry_nmi_exit(regs, state);
> }

That is correct for the NMI handler; but here I'm specifically talking
about traps, like the unalign trap, break trap etc. Those that can
happen *anywhere* in kernel code and nest most unfortunate.

WARNING: multiple messages have this Message-ID (diff)
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, palmer@dabbelt.com,
	paul.walmsley@sifive.com, mark.rutland@arm.com,
	zouyipeng@huawei.com, bigeasy@linutronix.de,
	David.Laight@aculab.com, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [PATCH V5 07/11] riscv: convert to generic entry
Date: Tue, 20 Sep 2022 09:22:50 +0200	[thread overview]
Message-ID: <YylqSsL6bdhIOMte@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJF2gTRdkmemEWsDYhVXb8KD0PS6b1VAPu_MfeZ+Rmf2qEGa6Q@mail.gmail.com>

On Tue, Sep 20, 2022 at 02:36:33PM +0800, Guo Ren wrote:
> On Mon, Sep 19, 2022 at 9:34 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Sun, Sep 18, 2022 at 11:52:42AM -0400, guoren@kernel.org wrote:
> >
> > > @@ -123,18 +126,22 @@ int handle_misaligned_store(struct pt_regs *regs);
> > >
> > >  asmlinkage void __trap_section do_trap_load_misaligned(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > >       if (!handle_misaligned_load(regs))
> > >               return;
> > >       do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> > >                     "Oops - load address misaligned");
> > > +     irqentry_exit(regs, state);
> > >  }
> > >
> > >  asmlinkage void __trap_section do_trap_store_misaligned(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > >       if (!handle_misaligned_store(regs))
> > >               return;
> > >       do_trap_error(regs, SIGBUS, BUS_ADRALN, regs->epc,
> > >                     "Oops - store (or AMO) address misaligned");
> > > +     irqentry_exit(regs, state);
> > >  }
> > >  #endif
> > >  DO_ERROR_INFO(do_trap_store_fault,
> > > @@ -158,6 +165,8 @@ static inline unsigned long get_break_insn_length(unsigned long pc)
> > >
> > >  asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
> > >  {
> > > +     irqentry_state_t state = irqentry_enter(regs);
> > > +
> > >  #ifdef CONFIG_KPROBES
> > >       if (kprobe_single_step_handler(regs))
> > >               return;
> >
> > FWIW; on x86 I've classified many of the 'from-kernel' traps as
> > NMI-like, since those traps can happen from any context, including with
> > IRQs disabled.
> The do_trap_break is for ebreak instruction, not NMI. RISC-V NMI has
> separate CSR. ref:
> 
> This proposal adds support for resumable non-maskable interrupts
> (RNMIs) to RISC-V. The extension adds four new CSRs (`mnepc`,
> `mncause`, `mnstatus`, and `mnscratch`) to hold the interrupted state,
> and a new instruction to resume from the RNMI handler.

Yes, but that's not what I'm saying. I'm saying I've classified
'from-kernel' traps as NMI-like.

Consider:

	raw_spin_lock_irq(&foo);
	...
	<trap>

Then you want the trap to behave as if it were an NMI; that is abide by
the rules of NMI (strictly wait-free code).

So yes, they are not NMI, but they nest just like it, so we want the
handlers to abide by the same rules.

Does that make sense?

> >
> > The basic shape of the trap handlers looks a little like:
> >
> >         if (user_mode(regs)) {
> If nmi comes from user_mode, why we using
> irqenrty_enter/exit_from/to_user_mode instead of
> irqentry_nmi_enter/exit?

s/nmi/trap/ because the 'from-user' trap never nests inside kernel code.

Additionally, many 'from-user' traps want to do 'silly' things like send
signals, which is something that requires scheduling.

They're fundamentally different from 'from-kernel' traps, which per the
above, nest most dangerously.

> >                 irqenrty_enter_from_user_mode(regs);
> >                 do_user_trap();
> >                 irqentry_exit_to_user_mode(regs);
> >         } else {
> >                 irqentry_state_t state = irqentry_nmi_enter(regs);
> >                 do_kernel_trap();
> >                 irqentry_nmi_exit(regs, state);
> >         }
> >
> > Not saying you have to match Risc-V in this patch-set, just something to
> > consider.
> I think the shape of the riscv NMI handler looks a little like this:
> 
> asmlinkage __visible __trap_section void do_trap_nmi(struct pt_regs *regs)
> {
>                  irqentry_state_t state = irqentry_nmi_enter(regs);
>                  do_nmi_trap();
>                  irqentry_nmi_exit(regs, state);
> }

That is correct for the NMI handler; but here I'm specifically talking
about traps, like the unalign trap, break trap etc. Those that can
happen *anywhere* in kernel code and nest most unfortunate.

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

  reply	other threads:[~2022-09-20  7:24 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-18 15:52 [PATCH V5 00/11] riscv: Add GENERIC_ENTRY support and related features guoren
2022-09-18 15:52 ` guoren
2022-09-18 15:52 ` [PATCH V5 01/11] riscv: elf_kexec: Fixup compile warning guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 02/11] riscv: compat_syscall_table: " guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 03/11] riscv: ptrace: Remove duplicate operation guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 04/11] compiler_types.h: Add __noinstr_section() for noinstr guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 05/11] riscv: traps: Add noinstr to prevent instrumentation inserted guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 06/11] entry: Prevent DEBUG_PREEMPT warning guoren
2022-09-18 15:52   ` guoren
2022-09-19 11:58   ` Peter Zijlstra
2022-09-19 11:58     ` Peter Zijlstra
2022-09-20  1:45     ` Guo Ren
2022-09-20  1:45       ` Guo Ren
2022-09-30 12:27       ` Guo Ren
2022-09-30 12:27         ` Guo Ren
2022-09-18 15:52 ` [PATCH V5 07/11] riscv: convert to generic entry guoren
2022-09-18 15:52   ` guoren
2022-09-19 13:34   ` Peter Zijlstra
2022-09-19 13:34     ` Peter Zijlstra
2022-09-20  6:36     ` Guo Ren
2022-09-20  6:36       ` Guo Ren
2022-09-20  7:22       ` Peter Zijlstra [this message]
2022-09-20  7:22         ` Peter Zijlstra
2022-09-30 11:28         ` Guo Ren
2022-09-30 11:28           ` Guo Ren
2022-09-18 15:52 ` [PATCH V5 08/11] riscv: Support HAVE_IRQ_EXIT_ON_IRQ_STACK guoren
2022-09-18 15:52   ` guoren
2022-09-19 13:45   ` Peter Zijlstra
2022-09-19 13:45     ` Peter Zijlstra
2022-09-20  6:08     ` Guo Ren
2022-09-20  6:08       ` Guo Ren
2022-09-20  7:27       ` Peter Zijlstra
2022-09-20  7:27         ` Peter Zijlstra
2022-09-20  7:34         ` Peter Zijlstra
2022-09-20  7:34           ` Peter Zijlstra
2022-09-21  6:16           ` Guo Ren
2022-09-21  6:16             ` Guo Ren
2022-09-21  8:34   ` Chen Zhongjin
2022-09-21  8:34     ` Chen Zhongjin
2022-09-21  9:53     ` Guo Ren
2022-09-21  9:53       ` Guo Ren
2022-09-21 11:56       ` Chen Zhongjin
2022-09-21 11:56         ` Chen Zhongjin
2022-09-22  1:26         ` Guo Ren
2022-09-22  1:26           ` Guo Ren
2022-09-18 15:52 ` [PATCH V5 09/11] riscv: Support HAVE_SOFTIRQ_ON_OWN_STACK guoren
2022-09-18 15:52   ` guoren
2022-09-20  0:11   ` Guo Ren
2022-09-20  0:11     ` Guo Ren
2022-09-18 15:52 ` [PATCH V5 10/11] riscv: Add config of thread stack size guoren
2022-09-18 15:52   ` guoren
2022-09-18 15:52 ` [PATCH V5 11/11] riscv: Add support for STACKLEAK gcc plugin guoren
2022-09-18 15:52   ` guoren

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=YylqSsL6bdhIOMte@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=David.Laight@aculab.com \
    --cc=apatel@ventanamicro.com \
    --cc=arnd@arndb.de \
    --cc=atishp@atishpatra.org \
    --cc=bigeasy@linutronix.de \
    --cc=chenhuacai@kernel.org \
    --cc=conor.dooley@microchip.com \
    --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=paul.walmsley@sifive.com \
    --cc=tglx@linutronix.de \
    --cc=zouyipeng@huawei.com \
    /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.