[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251001113505.25281444@gandalf.local.home>
Date: Wed, 1 Oct 2025 11:35:05 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: jpoimboe@...nel.org, rostedt@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/12] unwind: Add comment to
unwind_deferred_task_exit()
On Wed, 24 Sep 2025 09:59:53 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> Explain why unwind_deferred_task_exit() exist and its constraints.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> ---
> kernel/exit.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -934,7 +934,6 @@ void __noreturn do_exit(long code)
>
> tsk->exit_code = code;
> taskstats_exit(tsk, group_dead);
> - unwind_deferred_task_exit(tsk);
> trace_sched_process_exit(tsk, group_dead);
>
> /*
> @@ -945,6 +944,12 @@ void __noreturn do_exit(long code)
> * gets woken up by child-exit notifications.
> */
> perf_event_exit_task(tsk);
> + /*
> + * PF_EXITING (above) ensures unwind_deferred_request() will no
> + * longer add new unwinds. While exit_mm() (below) will destroy the
> + * abaility to do unwinds.
I would state that it also flushes any unwind that is currently pending, as
exit_mm() will prevent it from happening.
-- Steve
> + */
> + unwind_deferred_task_exit(tsk);
>
> exit_mm();
>
>
Powered by blists - more mailing lists