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

Steven Rostedt
2022-07-22T21:41:27Z

On Fri, 22 Jul 2022 23:05:19 +0200
Jiri Olsa <olsajiri@gmail.com> wrote:

> ok, I think we could use that, I'll check
>
> >
> > But other than that, we don't need infrastructure to hide any mcount/fentry
> > locations from ftrace. Those were add *for* ftrace.
>
> I think I understand the fentry/ftrace equivalence you see, I remember
> the perl mcount script ;-)

It's even more than that. We worked with the compiler folks to get fentry
for ftrace purposes (namely to speed it up, and not rely on frame
pointers, which mcount did). fentry never existed until then. Like I said.
fentry was created *for* ftrace. And currently it's x86 specific, as it
relies on the calling convention that a call does both, push the return
address onto the stack, and jump to a function. The blr
(branch-link-register) method is more complex, which is where the
"patchable" work comes from.

>
> still I think we should be able to define function that has fentry
> profile call and be able to manage it without ftrace
>
> one other thought.. how about adding function that would allow to disable
> function in ftrace, with existing FTRACE_FL_DISABLED or some new flag
>
> that way ftrace still keeps track of it, but won't allow to use it in
> ftrace infra

Another way is to remove it at compile time from the mcount_loc table, and
add it to your own table. I take it, this is for bpf infrastructure code
and not for any code that's in the day to day processing of the kernel,
right?

-- Steve