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

[Gabriele Monaco <gmonaco@redhat.com>]

 
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?