Re: [PATCH v4 12/12] riscv: Documentation: add a description about dynamic ftrace

[Robbin Ehn <rehn@rivosinc.com>]

Hi, thanks,

s/atmoic/atomic

On Tue, 2025-04-08 at 02:08 +0800, Andy Chiu wrote:
> +without a race condition. This series makes atmoic code patching possible in
...
> +setting the first instruction to AUIPC, and the second to NOP. Now, atmoic

/Robbin

> +patching is possible because the kernel only has to update one instruction.
> +According to Ziccif, as long as an instruction is naturally aligned, the ISA
> +guarantee an  atomic update.
> +
> +By fixing down the first instruction, AUIPC, the range of the ftrace
> trampoline
> +is limited to +-2K from the predetermined target, ftrace_caller, due to the
> lack
> +of immediate encoding space in RISC-V. To address the issue, we introduce
> +CALL_OPS, where an 8B naturally align metadata is added in front of each
> +pacthable function. The metadata is resolved at the first trampoline, then
> the
> +execution can be derect to another custom trampoline.
> +
> +CMODX in the User Space
> +---------------------
> +
> +Though fence.i is an unprivileged instruction, the default Linux ABI
> prohibits
> +the use of fence.i in userspace applications. At any point the scheduler may
> +migrate a task onto a new hart. If migration occurs after the userspace
> +synchronized the icache and instruction storage with fence.i, the icache on
> the
> +new hart will no longer be clean. This is due to the behavior of fence.i only
> +affecting the hart that it is called on. Thus, the hart that the task has
> been
> +migrated to may not have synchronized instruction storage and icache.
>  
>  There are two ways to solve this problem: use the riscv_flush_icache()
> syscall,
>  or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl() and emit fence.i in