[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240220100857.3f450059@gandalf.local.home>
Date: Tue, 20 Feb 2024 10:08:57 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Oleg Nesterov <oleg@...hat.com>, wenyang.linux@...mail.com, Masami
Hiramatsu <mhiramat@...nel.org>, Ingo Molnar <mingo@...nel.org>, Mel Gorman
<mgorman@...hsingularity.net>, Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] coredump debugging: add a tracepoint to report the
coredumping
On Mon, 19 Feb 2024 13:01:16 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> No ? Those hook on sched_process_free, which is the actual point where the
> task is freed (AFAIR after it's been a zombie and then waited for by another
> task).
Bah, you're correct. It *used to* be attached to sched_process_exit, and
the function callback still has that name. It was commit afcab63665742
("tracing: Use trace_sched_process_free() instead of exit() for pid
tracing") that changed it.
>
> AFAIU, "sched_process_exit" is issued close to the point where the task exits
> (it should not go back to userspace after that). "sched_process_free" is done
> when the task is really being removed.
>
> Between "sched_process_exit" and "sched_process_free", the task can still be
> observed by a trace analysis looking at sched and signal events: it's a zombie at
> that stage.
Right, thanks for reminding me what I did ;-) I guess I'm starting to get to "that age".
-- Steve
Powered by blists - more mailing lists