[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250819145345.GL3289052@noisy.programming.kicks-ass.net>
Date: Tue, 19 Aug 2025 16:53:45 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Oleg Nesterov <oleg@...hat.com>, Andrii Nakryiko <andrii@...nel.org>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, x86@...nel.org,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
Hao Luo <haoluo@...gle.com>, Steven Rostedt <rostedt@...dmis.org>,
Alan Maguire <alan.maguire@...cle.com>,
David Laight <David.Laight@...lab.com>,
Thomas Weißschuh <thomas@...ch.de>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCHv6 perf/core 08/22] uprobes/x86: Add mapping for optimized
uprobe trampolines
On Sun, Jul 20, 2025 at 01:21:18PM +0200, Jiri Olsa wrote:
> +static void destroy_uprobe_trampoline(struct uprobe_trampoline *tramp)
> +{
> + /*
> + * We do not unmap and release uprobe trampoline page itself,
> + * because there's no easy way to make sure none of the threads
> + * is still inside the trampoline.
> + */
> + hlist_del(&tramp->node);
> + kfree(tramp);
> +}
I am somewhat confused; isn't this called from
__mmput()->uprobe_clear_state()->arch_uprobe_clear_state ?
At that time we don't have threads anymore and mm is about to be
destroyed anyway.
Powered by blists - more mailing lists