> On Dec 8, 2025, at 15:19, Masami Hiramatsu (Google) <[email protected]> > wrote: > > On Mon, 8 Dec 2025 14:54:33 +0800 > qingwei hu <[email protected]> wrote: > >> >> >>> 2025年12月5日 23:08，Steven Rostedt <[email protected]> 写道： >>> >>> On Fri, 5 Dec 2025 17:29:33 +0800 >>> "qingwei.hu" <[email protected]> wrote: >>> >>>> From: Qingwei Hu <[email protected]> >>>> >>>> There is a possible configuration dependency: >>>> >>>> KPROBES_ON_FTRACE [=n] >>>> ^----- KPROBES [=y] >>>> |--- HAVE_KPROBES_ON_FTRACE [=n] >>>> |--- DYNAMIC_FTRACE_WITH_REGS [=n] >>>> ^----- FTRACE [=y] >>>> |--- DYNAMIC_FTRACE [=y] >>>> |--- HAVE_DYNAMIC_FTRACE_WITH_REGS [=n] >>>> >>>> With DYNAMIC_FTRACE=y, ftrace_location() is meaningful and may >>>> return the same address as the probe target. >>>> >>>> However, when KPROBES_ON_FTRACE=n, the current implementation >>>> returns -EINVAL after calling check_ftrace_location(), causing >>>> the validation to fail. >>> >>> This is a feature not a bug. >>> >>> The reason is if you put a kprobe on a ftrace location, it can cause ftrace >>> to trigger a bug, as kprobes will modify the location and ftrace will see >>> something it doesn't expect and think the system is corrupted. We don't want >>> that either. >>> >>> If you say "KPROBES_ON_FTRACE=n" and place a kprobe on a location that is >>> controlled by ftrace, it had better fail! >>> >>> NAK >>> >>> -- Steve >> >> Thanks for your clear explanation. I will look into other approaches >> that work with this configuration. >> > > Can you check the code under arch/<your machine>/ implements the > kprobe_ftrace_handler() correctly? if so, it should be enabled automatically. > > Thank you, > > > -- > Masami Hiramatsu (Google) <[email protected]>
I am working on the risc-v that have removed support for KPROBE_ON_FTRACE and probe_ftrace_hander() since 7caa9765465f60 and 3308172276db5d. As 7caa9765465f60 commit say KPROBES_ON_FTRACE will be supplanted by FPROBES, I have tested and verified this feature's usability. In this situation, may be we should use fprobe instead of kprobe. But in the latest version, risc-v adjusts ftrace location to an offset 4 byte from the function symbol. So it will kprobe successfully in the beginning of the symbol while not support KPROBE_ON_FTRACE. I am not sure whether this arrangement is consistent with Steve’s explanation. If the adjustment is valid, I can temporarily backport the adjust function in order to support kprobe.
