ftrace_direct_func_count ?

ftrace_direct_func_count ?

[Dr. David Alan Gilbert]

Hi,
  I've just posted a patch 'ftrace: Remove unused list 'ftrace_direct_funcs''
that clears out some old code, but while at it I noticed the global
'ftrace_direct_func_count'.

As far as I can tell, it's never assigned (or initialised) but it is tested:

kernel/trace/fgraph.c:
#ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
  /*
   * Skip graph tracing if the return location is served by direct trampoline,
   * since call sequence and return addresses are unpredictable anyway.
   * Ex: BPF trampoline may call original function and may skip frame
   * depending on type of BPF programs attached.
   */
  if (ftrace_direct_func_count &&
      ftrace_find_rec_direct(ret - MCOUNT_INSN_SIZE))
    return -EBUSY;
#endif

So I wasn't sure whether it was just safe to nuke that section
or whether it really needed fixing?

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: ftrace_direct_func_count ?

[Steven Rostedt]

On Sat, 4 May 2024 13:35:26 +0000
"Dr. David Alan Gilbert" <dave@treblig.org> wrote:

> Hi,
>   I've just posted a patch 'ftrace: Remove unused list 'ftrace_direct_funcs''
> that clears out some old code, but while at it I noticed the global
> 'ftrace_direct_func_count'.
> 
> As far as I can tell, it's never assigned (or initialised) but it is tested:
> 
> kernel/trace/fgraph.c:
> #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
>   /*
>    * Skip graph tracing if the return location is served by direct trampoline,
>    * since call sequence and return addresses are unpredictable anyway.
>    * Ex: BPF trampoline may call original function and may skip frame
>    * depending on type of BPF programs attached.
>    */
>   if (ftrace_direct_func_count &&
>       ftrace_find_rec_direct(ret - MCOUNT_INSN_SIZE))
>     return -EBUSY;
> #endif
> 
> So I wasn't sure whether it was just safe to nuke that section
> or whether it really needed fixing?

Yes, after commit 8788ca164eb4bad ("ftrace: Remove the legacy
_ftrace_direct API") that variable is no longer used.

-- Steve

Re: ftrace_direct_func_count ?

[Dr. David Alan Gilbert]

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Sat, 4 May 2024 13:35:26 +0000
> "Dr. David Alan Gilbert" <dave@treblig.org> wrote:
> 
> > Hi,
> >   I've just posted a patch 'ftrace: Remove unused list 'ftrace_direct_funcs''
> > that clears out some old code, but while at it I noticed the global
> > 'ftrace_direct_func_count'.
> > 
> > As far as I can tell, it's never assigned (or initialised) but it is tested:
> > 
> > kernel/trace/fgraph.c:
> > #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
> >   /*
> >    * Skip graph tracing if the return location is served by direct trampoline,
> >    * since call sequence and return addresses are unpredictable anyway.
> >    * Ex: BPF trampoline may call original function and may skip frame
> >    * depending on type of BPF programs attached.
> >    */
> >   if (ftrace_direct_func_count &&
> >       ftrace_find_rec_direct(ret - MCOUNT_INSN_SIZE))
> >     return -EBUSY;
> > #endif
> > 
> > So I wasn't sure whether it was just safe to nuke that section
> > or whether it really needed fixing?
> 
> Yes, after commit 8788ca164eb4bad ("ftrace: Remove the legacy
> _ftrace_direct API") that variable is no longer used.

OK, thanks, I'll send a follow up patch to my other patch to nuke
this as well.

Dave

> -- Steve
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/