Question about earlier dynamic ftrace implementation with interrupt
Vivian Wang
wangruikang at iscas.ac.cn
Wed Jul 30 19:16:55 PDT 2025
On 7/31/25 08:57, Juhan Jin wrote:
> I was looking at earlier dynamic ftrace implementation which used
> stop_machine for text patching, and I have a question about interrupt
> occurred between patched instructions.
>
> Let's use commit 6724a76cff85 (riscv: ftrace: Reduce the detour code
> size to half, 2023-01-12) as code base. This commit places 2 4-byte
> NOPs at the start of each function. These NOPs can be patched to
> AUIPC t0, imm and JALR t0, t0(imm) to enable function tracer.
>
> Say we want to enable function tracer for kernel function `func`.
> Consider the following scenario:
>
> - Before enabling `func` for function tracer, its first 2 instructions
> are NOP and NOP.
>
> - After hart A executes the first NOP at the start of `func`, an
> interrupt occurs and hart A handles it.
>
> - While hart A is handling this interrupt, hart B enables function
> tracer for `func` and stop_machine is called. IPI to hart A is
> pending.
>
> - After hart A handles this interrupt and sret, the pending IPI is
> serviced. So instead of executing the second NOP, hart A executes
> IPI handler for stop_machine and enter quiescent state.
>
> - Hart B patches the 2 NOPs at the start of `func` to AUIPC and JALR
>
> - Hart A is released from quiescent state and resumes execution.
> However, hart A will now execute JALR instead of NOP.
>
> - NOP plus JALR leads to illegal jump target
>
> Is this scenario possible or did I just overlook something?
The old ftrace implementation did not support CONFIG_PREEMPTION=y
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && !PREEMPTION
Therefore, it is not possible for a stop_machine to hit between the two
instructions at the start of a function, because stop_machine will not
interrupt while preemption is disabled.
Vivian "dramforever" Wang
More information about the linux-riscv
mailing list