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

From: Nam Cao <namcaov@gmail.com>
To: "Björn Töpel" <bjorn@kernel.org>
Cc: 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,
	guoren@kernel.org
Subject: Re: [PATCH] riscv: provide riscv-specific is_trap_insn()
Date: Mon, 28 Aug 2023 15:31:15 +0200	[thread overview]
Message-ID: <ZOyhozSq3S36eRSq@nam-dell> (raw)
In-Reply-To: <874jkjl4e1.fsf@all.your.base.are.belong.to.us>

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.

Best regards,
Nam

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