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