Messages in this thread | | | From | Nam Cao <> | Date | Wed, 30 Aug 2023 09:56:37 +0200 | Subject | Re: [PATCH] riscv: provide riscv-specific is_trap_insn() |
| |
On Wed, Aug 30, 2023 at 9:46 AM Nam Cao <namcaov@gmail.com> wrote: > > On Wed, Aug 30, 2023 at 9:32 AM Björn Töpel <bjorn@kernel.org> wrote: > > > > Nam Cao <namcaov@gmail.com> writes: > > > > > On Tue, Aug 29, 2023 at 08:14:59AM +0200, Björn Töpel wrote: > > >> Nam Cao <namcaov@gmail.com> writes: > > >> > > >> > On Mon, Aug 28, 2023 at 03:31:15PM +0200, Nam Cao wrote: > > >> >> On Mon, Aug 28, 2023 at 02:48:06PM +0200, Björn Töpel wrote: > > >> >> > Nam Cao <namcaov@gmail.com> writes: > > >> >> > > > >> >> > > 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. > > >> >> > > > >> >> > I took this for a spin, and it indeed fixes this new hang! Nice! > > >> >> > > >> >> Great! Thanks for testing it. > > >> >> > > >> >> > However, when I tried setting an uprobe on the ebreak instruction > > >> >> > (offset 0x118) from your example [1], the probe does not show up in the > > >> >> > trace buffer. > > >> >> > > > >> >> > Any ideas? > > >> >> > > >> >> >From my understanding, both uprobes and kprobes refuse to install break points > > >> >> into existing trap instructions. Otherwise, we may conflict with something else > > >> >> that is also using trap instructions. > > >> > > > >> > I just realize you probably ask this because uprobe can still be installed before > > >> > applying the patch. But I think that is another bug that my patch also > > >> > accidentally fix: uprobes should not install breakpoint into ebreak instructions, > > >> > but it incorrectly does so because it does not even know about the existence of > > >> > 32-bit ebreak. > > >> > > >> FWIW, I can still install the uprobe at an ebreak with you patch. It's > > >> not hit, but succeeds to install. > > > > > > It seems uprobes install failures are completely silent (see uprobe_mmap() in > > > kernel/events/uprobes.c). So I think although uprobes install seems fine, it > > > actually is not. > > > > Huh, so there's no check if the instruction is a valid one at event > > register point? > > There are some checks (eg. if the probe is within the binary), but > they are not complete.
Oh wait, ignore that, just tested, this is also not checked.
> The actual checks for the validity of the instruction is not done > until installation. > > Best regards, > Nam
| |