On Fri, Jul 22, 2022 at 4:26 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Fri, 22 Jul 2022 13:08:11 +0200 > Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > hi, > > we recently hit bug where ftrace update raced with bpf_dispatcher_update > > that calls directly bpf_arch_text_poke [1]. > > > > The bpf_dispatcher_update creates special trampoline and attaches it to > > designated bpf_dispatcher_xdp_func function, which is run for xdp bpf > > programs from several places. > > > > After discussion with Alexei we'd rather keep this code update out of > > ftrace, because it's already slow and had troubles with CI because of > > that. > > > > This patch is presenting the idea to allow some functions not to be > > managed by ftrace by marking them with NOFTRACE_SYMBOL macro and > > such symbols will not be added to ftrace_pages on the kernel start. > > NACK on any generic way to hide mcount/fentry functions from ftrace. > > There's a lot of infrastructure to see what functions are being > modified, as the user should know. (See tracefs/enabled_functions). > > There's no need for a generic way to hide functions. Once that happens, > it will grow and then it will be more confusing to why some functions are > traced while others are not. Steven, ftrace must not peek into bpf specific functions. Currently ftrace is causing the kernel to crash. What Jiri is proposing is to fix ftrace bug. And you're saying nack? let ftrace be broken ? If you don't like Jiri's approach please propose something else.
