Re: [RFC] ftrace: Add support to keep some functions out of ftrace

Steven Rostedt
2022-07-22T16:25:56Z

On Fri, 22 Jul 2022 12:08:54 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 22 Jul 2022 09:04:29 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > 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 ?

Sounds like a BPF bug to me. Ftrace did nothing to cause this breakage. It
was something BPF must have done. What exactly is BPF doing to ftrace
locations anyway?

> >
> > If you don't like Jiri's approach please propose something else.
>
> So, why not mark it as notrace? That will prevent ftrace from looking at it.
>

And if for some strange reason you need the mcount/fentry on some internal
BPF infrastructure, the work around is to register two ftrace_ops() that
have filters to that function. In which case ftrace will force the call to
the ftrace iterator loop, and any more ops attached will simply be added to
that loop, and ftrace will no longer touch that location.

Then you can do whatever you want to it without fear of racing with ftrace.

But other than that, we don't need infrastructure to hide any mcount/fentry
locations from ftrace. Those were add *for* ftrace.

-- Steve