Hi,

On 11.05.2023 10:19, Björn Töpel wrote:

Song Shuai [off-list ref] writes:

quoted

This patch adds DYNAMIC_FTRACE_WITH_DIRECT_CALLS support for RISC-V.

select the DYNAMIC_FTRACE_WITH_DIRECT_CALLS to provide the
register_ftrace_direct[_multi] interfaces allowing users to register
the customed trampoline (direct_caller) as the mcount for one or
more target functions. And modify_ftrace_direct[_multi] are also
provided for modifying direct_caller.

To make the direct_caller and the other ftrace hooks (eg. function/fgraph
tracer, k[ret]probes) co-exist, a temporary register is nominated to
store the address of direct_caller in ftrace_regs_caller. After the
setting of the address direct_caller by direct_ops->func and the
RESTORE_REGS in ftrace_regs_caller, direct_caller will be jumped to
by the `jr` inst.

Signed-off-by: Song Shuai <redacted>
Tested-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Guo Ren <guoren@kernel.org>
---
  arch/riscv/Kconfig              |  1 +
  arch/riscv/include/asm/ftrace.h |  8 ++++++++
  arch/riscv/kernel/mcount-dyn.S  | 10 ++++++++++
  3 files changed, 19 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e0632493482f..fdf0b219a02c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig

@@ -144,6 +144,7 @@ config RISCV
       select UACCESS_MEMCPY if !MMU
       select ZONE_DMA32 if 64BIT
       select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && MMU && (CLANG_SUPPORTS_DYNAMIC_FTRACE || GCC_SUPPORTS_DYNAMIC_FTRACE)
+     select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
       select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
       select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
       select HAVE_FUNCTION_GRAPH_TRACER

diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index 84f856a3286e..84904c1e4369 100644
--- a/arch/riscv/include/asm/ftrace.h
+++ b/arch/riscv/include/asm/ftrace.h

@@ -114,6 +114,14 @@ struct ftrace_regs;
  void ftrace_graph_func(unsigned long ip, unsigned long parent_ip,
                      struct ftrace_ops *op, struct ftrace_regs *fregs);
  #define ftrace_graph_func ftrace_graph_func
+
+static inline void
+__arch_ftrace_set_direct_caller(struct pt_regs *regs, unsigned long addr)
+{
+             regs->t1 = addr;
+}
+#define arch_ftrace_set_direct_caller(fregs, addr) \
+     __arch_ftrace_set_direct_caller(&(fregs)->regs, addr)
  #endif /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */

  #endif /* __ASSEMBLY__ */

diff --git a/arch/riscv/kernel/mcount-dyn.S b/arch/riscv/kernel/mcount-dyn.S
index f26e9f6e2fed..9d405baedb52 100644
--- a/arch/riscv/kernel/mcount-dyn.S
+++ b/arch/riscv/kernel/mcount-dyn.S

@@ -231,6 +231,7 @@ ENDPROC(ftrace_caller)

  #else /* CONFIG_DYNAMIC_FTRACE_WITH_REGS */
  ENTRY(ftrace_regs_caller)
+     move    t1, zero

Please use "mv", and not "move" [1].

quoted

       SAVE_ABI_REGS 1
       PREPARE_ARGS

@@ -239,7 +240,10 @@ ftrace_regs_call:
       call    ftrace_stub

       RESTORE_ABI_REGS 1
+     bnez    t1,.Ldirect
       jr t0
+.Ldirect:
+     jr t1

Again, while you're doing changes here, please try to align op/operands.

Wearing my BPF hat, I'm happy to finally get DIRECT_CALLS support!

This does not take the WITH_CALL_OPS approach Mark suggested in the v7
threads, but given that text patching story on RISC-V is still a bit sad
(inconsistency in the RV tree, no specification, cannot work with
preempt, ...) I'd say this approach is OK for now, and we can change to
WITH_CALL_OPS later in a wider "let's improve RISC-V textpatching" work.

Thoughts?

The WITH_CALL_OPS approach seems to need much more time and effort, so, 
yes, I'd also use this implementation of DIRECT_CALLS for now. Other 
improvements could wait for the future "big patching rework".

FWIW, the implementation of kprobes for RISC-V has been improving 
gradually too, not everything was done in the first very patchset, but 
it was usable nonetheless.

I have not tested this particular version of this 
DYNAMIC_FTRACE_WITH_DIRECT_CALLS series, only some previous ones - there 
were no outstanding problems there. The code looks sane to me.

Björn

[1] https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#-a-listing-of-standard-risc-v-pseudoinstructions

Regards,
Evgenii