From: Nam Cao <namcaov@gmail.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Guo Ren <guoren@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
bjorn@kernel.org
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()
Date: Tue, 29 Aug 2023 10:12:28 +0200 [thread overview]
Message-ID: <ZO2obGvrqWsl1VvY@nam-dell> (raw)
In-Reply-To: <20230829-unbridle-condense-2fc45a442bb6@wendy>
On Tue, Aug 29, 2023 at 07:26:54AM +0100, Conor Dooley wrote:
> On Tue, Aug 29, 2023 at 01:56:34PM +0800, Guo Ren wrote:
> > On Mon, Aug 28, 2023 at 4:56 AM Nam Cao <namcaov@gmail.com> wrote:
> > >
> > > uprobes expects is_trap_insn() to return true for any trap instructions,
> > > not just the one used for installing uprobe. The current default
> > > implementation only returns true for 16-bit c.ebreak if C extension is
> > > enabled. This can confuse uprobes if a 32-bit ebreak generates a trap
> > > exception from userspace: uprobes asks is_trap_insn() who says there is no
> > > trap, so uprobes assume a probe was there before but has been removed, and
> > > return to the trap instruction. This cause an infinite loop of entering
> > > and exiting trap handler.
> > >
> > > Instead of using the default implementation, implement this function
> > > speficially for riscv which checks for both ebreak and c.ebreak.
> > >
> > > Fixes: 74784081aac8 ("riscv: Add uprobes supported")
> > > Signed-off-by: Nam Cao <namcaov@gmail.com>
> > > ---
> > > arch/riscv/kernel/probes/uprobes.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c
> > > index 194f166b2cc4..91f4ce101cd1 100644
> > > --- a/arch/riscv/kernel/probes/uprobes.c
> > > +++ b/arch/riscv/kernel/probes/uprobes.c
> > > @@ -3,6 +3,7 @@
> > > #include <linux/highmem.h>
> > > #include <linux/ptrace.h>
> > > #include <linux/uprobes.h>
> > > +#include <asm/insn.h>
> > >
> > > #include "decode-insn.h"
> > >
> > > @@ -17,6 +18,15 @@ bool is_swbp_insn(uprobe_opcode_t *insn)
> > > #endif
> > > }
> > >
> > > +bool is_trap_insn(uprobe_opcode_t *insn)
> > > +{
> > > +#ifdef CONFIG_RISCV_ISA_C
>
> > Can we remove the CONFIG_RISCV_ISA_C? As you said, "uprobes expects
> > is_trap_insn() to return true for any trap instructions". So userspace
> > wouldn't be limited by CONFIG_RISCV_ISA_C.
>
> Isn't the RISCV_ISA_C required because there's a different encoding for
> EBREAK vs C_EBREAK?
riscv_insn_is_c_ebreak() can be used without enabling RISCV_ISA_C, so no it's
not required.
Best regards,
Nam
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Nam Cao <namcaov@gmail.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Guo Ren <guoren@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
bjorn@kernel.org
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()
Date: Tue, 29 Aug 2023 10:12:28 +0200 [thread overview]
Message-ID: <ZO2obGvrqWsl1VvY@nam-dell> (raw)
In-Reply-To: <20230829-unbridle-condense-2fc45a442bb6@wendy>
On Tue, Aug 29, 2023 at 07:26:54AM +0100, Conor Dooley wrote:
> On Tue, Aug 29, 2023 at 01:56:34PM +0800, Guo Ren wrote:
> > On Mon, Aug 28, 2023 at 4:56 AM Nam Cao <namcaov@gmail.com> wrote:
> > >
> > > uprobes expects is_trap_insn() to return true for any trap instructions,
> > > not just the one used for installing uprobe. The current default
> > > implementation only returns true for 16-bit c.ebreak if C extension is
> > > enabled. This can confuse uprobes if a 32-bit ebreak generates a trap
> > > exception from userspace: uprobes asks is_trap_insn() who says there is no
> > > trap, so uprobes assume a probe was there before but has been removed, and
> > > return to the trap instruction. This cause an infinite loop of entering
> > > and exiting trap handler.
> > >
> > > Instead of using the default implementation, implement this function
> > > speficially for riscv which checks for both ebreak and c.ebreak.
> > >
> > > Fixes: 74784081aac8 ("riscv: Add uprobes supported")
> > > Signed-off-by: Nam Cao <namcaov@gmail.com>
> > > ---
> > > arch/riscv/kernel/probes/uprobes.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/riscv/kernel/probes/uprobes.c b/arch/riscv/kernel/probes/uprobes.c
> > > index 194f166b2cc4..91f4ce101cd1 100644
> > > --- a/arch/riscv/kernel/probes/uprobes.c
> > > +++ b/arch/riscv/kernel/probes/uprobes.c
> > > @@ -3,6 +3,7 @@
> > > #include <linux/highmem.h>
> > > #include <linux/ptrace.h>
> > > #include <linux/uprobes.h>
> > > +#include <asm/insn.h>
> > >
> > > #include "decode-insn.h"
> > >
> > > @@ -17,6 +18,15 @@ bool is_swbp_insn(uprobe_opcode_t *insn)
> > > #endif
> > > }
> > >
> > > +bool is_trap_insn(uprobe_opcode_t *insn)
> > > +{
> > > +#ifdef CONFIG_RISCV_ISA_C
>
> > Can we remove the CONFIG_RISCV_ISA_C? As you said, "uprobes expects
> > is_trap_insn() to return true for any trap instructions". So userspace
> > wouldn't be limited by CONFIG_RISCV_ISA_C.
>
> Isn't the RISCV_ISA_C required because there's a different encoding for
> EBREAK vs C_EBREAK?
riscv_insn_is_c_ebreak() can be used without enabling RISCV_ISA_C, so no it's
not required.
Best regards,
Nam
next prev parent reply other threads:[~2023-08-29 8:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-27 20:56 [PATCH] riscv: provide riscv-specific is_trap_insn() Nam Cao
2023-08-27 20:56 ` Nam Cao
2023-08-28 12:48 ` Björn Töpel
2023-08-28 12:48 ` Björn Töpel
2023-08-28 13:31 ` Nam Cao
2023-08-28 13:31 ` Nam Cao
2023-08-28 13:50 ` Nam Cao
2023-08-28 13:50 ` Nam Cao
2023-08-29 6:14 ` Björn Töpel
2023-08-29 6:14 ` Björn Töpel
2023-08-29 18:54 ` Nam Cao
2023-08-29 18:54 ` Nam Cao
2023-08-30 7:32 ` Björn Töpel
2023-08-30 7:32 ` Björn Töpel
2023-08-30 7:46 ` Nam Cao
2023-08-30 7:46 ` Nam Cao
2023-08-30 7:56 ` Nam Cao
2023-08-30 7:56 ` Nam Cao
2023-08-29 5:56 ` Guo Ren
2023-08-29 5:56 ` Guo Ren
2023-08-29 6:26 ` Conor Dooley
2023-08-29 6:26 ` Conor Dooley
2023-08-29 8:12 ` Nam Cao [this message]
2023-08-29 8:12 ` Nam Cao
2023-08-29 8:18 ` Nam Cao
2023-08-29 8:18 ` Nam Cao
2023-08-31 16:29 ` Conor Dooley
2023-08-31 16:29 ` Conor Dooley
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=ZO2obGvrqWsl1VvY@nam-dell \
--to=namcaov@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=guoren@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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.