[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250312101647.GK19424@noisy.programming.kicks-ass.net>
Date: Wed, 12 Mar 2025 11:16:47 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: mingo@...nel.org, lucas.demarchi@...el.com,
linux-kernel@...r.kernel.org, acme@...nel.org, namhyung@...nel.org,
mark.rutland@....com, alexander.shishkin@...ux.intel.com,
jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com
Subject: Re: [PATCH v3a 6/7] perf: Rename perf_event_exit_task(.child)
On Wed, Mar 12, 2025 at 12:01:00PM +0530, Ravi Bangoria wrote:
> Hi Peter,
>
> > The task passed to perf_event_exit_task() is not a child, it is
> > current. Fix this confusing naming, since much of the rest of the code
> > also relies on it being current.
> >
> > Specifically, both exec() and exit() callers use it with current as
> > the argument.
>
> When perf_event_exit_task_context() gets called by perf_event_free_task():
>
> 1) task_ctx_sched_out(ctx) function should be avoided because the 'ctx'
> argument is of the (half baked)child task whereas task_ctx_sched_out()
> expects 'ctx' to be the context of 'current'.
> 2) Similarly, 'task' argument != 'current'.
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -13573,7 +13573,8 @@ static void perf_event_exit_task_context(struct task_struct *task, bool exit)
> * in.
> */
> raw_spin_lock_irq(&ctx->lock);
> - task_ctx_sched_out(ctx, NULL, EVENT_ALL);
> + if (exit)
> + task_ctx_sched_out(ctx, NULL, EVENT_ALL);
>
> /*
> * Now that the context is inactive, destroy the task <-> ctx relation
> @@ -13582,7 +13583,7 @@ static void perf_event_exit_task_context(struct task_struct *task, bool exit)
> RCU_INIT_POINTER(task->perf_event_ctxp, NULL);
> put_ctx(ctx); /* cannot be last */
> WRITE_ONCE(ctx->task, TASK_TOMBSTONE);
> - put_task_struct(current); /* cannot be last */
> + put_task_struct(task); /* cannot be last */
>
> clone_ctx = unclone_ctx(ctx);
> raw_spin_unlock_irq(&ctx->lock);
Right you are. Thanks!
Powered by blists - more mailing lists