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
