Re: [PATCH v2 03/11] sched: Add sched tracepoints for RV task model

From: Gabriele Monaco
Date: Fri Feb 14 2025 - 06:15:46 EST



On Fri, 2025-02-14 at 16:00 +0800, kernel test robot wrote:

>  >    kernel/sched/core.c: In function
> '__do_trace_set_current_state':
>  

>  
> >  
> > >  > > > kernel/sched/core.c:503:9: error: implicit declaration of
> > > > > > function '__do_trace_sched_set_state_tp'; did you mean
> > > > > > 'trace_sched_set_state_tp'?
> > > > > > [-Werror=implicit-function-declaration]
> > >  
> >  
>  

>  >      503 |         __do_trace_sched_set_state_tp(current,
> > current->__state, state_value);
> >          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >          |         trace_sched_set_state_tp
> >    cc1: some warnings being treated as errors
> >
> >
> > vim +503 kernel/sched/core.c
> >
> >    496
> >    497 /*
> >    498 * Do not call this function directly since it won't check if
> > the tp is enabled.
> >    499 * Call the helper macro trace_set_current_state instead.
> >    500 */
> >    501 void __do_trace_set_current_state(int state_value)
> >    502 {
> >  > 503 __do_trace_sched_set_state_tp(current, current->__state,
> > state_value);
> >    504 }
> >    505 EXPORT_SYMBOL(__do_trace_set_current_state);
> >    506
>  

I honestly don't get why this build failed. The function __do_trace_
exists since cff6d93eab00ba ("tracepoint: Reduce duplication of
__DO_TRACE_CALL"), a while before that it was just a macro and not an
inline function, reason why no one so far used it directly.

Both failed builds are based on 4dc1d1bec898 (where my patchset is
based) and there __do_trace_ does exist.

Unless there's a strong opinion not to use it although the compiler
allows it, I'd consider the two kernel robot results false negatives.

Or am I missing something?