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?