Re: [PATCH] riscv: provide riscv-specific is_trap_insn()

[Nam Cao <namcaov@gmail.com>]

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.

Best regards,
Nam