On Wed, Sep 21, 2022 at 09:46:40AM +0200, Ingo Molnar wrote:
>
> * Li Zhong <floridsleeves@xxxxxxxxx> wrote:
>
> > From: lily <floridsleeves@xxxxxxxxx>
> >
> > Check the return value of task_function_call(), which could be error
> > code when the execution fails. We log this on info level.
> >
> > Signed-off-by: Li Zhong <floridsleeves@xxxxxxxxx>
> > ---
> > kernel/events/core.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 2621fd24ad26..3848631b009c 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -13520,7 +13520,10 @@ static void perf_cgroup_attach(struct cgroup_taskset *tset)
> > struct cgroup_subsys_state *css;
> >
> > cgroup_taskset_for_each(task, css, tset)
> > - task_function_call(task, __perf_cgroup_move, task);
> > + if (!task_function_call(task, __perf_cgroup_move, task)) {
> > + printk(KERN_INFO "perf: this process isn't running!\n");
> > + continue;
>
> If this is a 'should never happen' condition, then this should really be
> WARN_ON_ONCE().
>
> (If it can happen, then polluting the syslog is wrong.)
It can happen and is just fine. If this task_function_call() fails, it
means the context switch that made it fail ensured the new values have
been picked up.
