Re: [PATCH 1/2] riscv: kprobes: simulate nop and c.nop instructions

From: Nam Cao <namcao@linutronix.de>
To: Xiaofeng Yuan <yuanxiaofeng@eswincomputing.com>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>, Nam Cao <namcaov@gmail.com>,
	linux-riscv@lists.infradead.org, yuanxiaofeng@eswincomputing.com
Subject: Re: [PATCH 1/2] riscv: kprobes: simulate nop and c.nop instructions
Date: Wed, 19 Aug 2026 13:54:30 +0200	[thread overview]
Message-ID: <87zeyil409.fsf@yellow.woof> (raw)
In-Reply-To: <20260819101419.1367-2-yuanxiaofeng@eswincomputing.com>

Xiaofeng Yuan <yuanxiaofeng@eswincomputing.com> writes:

> nop and c.nop have no architectural effect, so allocating an
> out-of-line instruction slot and single-stepping through them is
> pure overhead. Simulate them directly in the breakpoint handler
> by advancing the program counter, following the approach already
> used on arm64.
>
> This avoids slot allocation, text patching, IRQ flag save/restore
> and the single-step exception for these instructions.
>
> Compile tested on RISC-V, and verified with the RISC-V kprobes
> KUnit test which now covers nop and c.nop.

For RISC-V, how common is installing probes on nop instructions?

Looking at the commit adding nop simulation on Arm, I see it is useful
for probes on USDT. Is this also the case for RISC-V?

Additionally, it would be great if there is a benchmark to justify
adding this.

Nam

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