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]>
