From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: bot+bpf-ci@kernel.org
Cc: josef@toxicpanda.com, paulmck@kernel.org, frederic@kernel.org,
ast@kernel.org, rostedt@goodmis.org, boqun@kernel.org,
mark.rutland@arm.com, peterz@infradead.org, tglx@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, puranjay@kernel.org,
rcu@vger.kernel.org, bpf@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, martin.lau@kernel.org,
eddyz87@gmail.com, yonghong.song@linux.dev, mason@kernel.org,
ihor.solodrai@linux.dev
Subject: Re: [PATCH] kprobes: Make optprobe optimizer multi-generational and asynchronous
Date: Sat, 26 Sep 2026 11:17:29 +0900 [thread overview]
Message-ID: <20260926111729.f580fa6a8eaac448649fc8e3@kernel.org> (raw)
In-Reply-To: <6469f266e0c06de407583746d4f533a03a002fa8d7871124196b0bb568fe38fa@mail.kernel.org>
On Thu, 24 Sep 2026 16:17:38 +0000 (UTC)
bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 6337da5cab9e..1e25980303c4 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
>
> [ ... ]
>
> > @@ -530,50 +553,78 @@ static DECLARE_COMPLETION(optimizer_completion);
> >
> > #define OPTIMIZE_DELAY 5
> >
> > +static bool optprobe_has_queued_probes(void)
> > +{
> > + struct optprobe_generation *gen = &optprobe_gens[optprobe_cur_gen];
> > +
> > + return !list_empty(&gen->optimizing_list) ||
> > + !list_empty(&gen->unoptimizing_list);
> > +}
>
> Does this logic need to check gen->freeing_list as well?
Ah, indeed. It should check the freeing_list too.
[ ... ]
>
> > @@ -622,67 +675,119 @@ static void do_free_cleaned_kprobes(void)
> >
> > static void kick_kprobe_optimizer(void);
> >
> > +static void optprobe_generation_rcu_cb(struct rcu_head *rcu)
> > +{
> > + struct optprobe_generation *gen;
> > +
> > + gen = container_of(rcu, struct optprobe_generation, rcu);
> > + WRITE_ONCE(gen->ready, true);
> > + wake_up(&kprobe_optimizer_wait);
> > +}
> > +
> > +static void optprobe_finalize_generation(struct optprobe_generation *gen)
> > +{
> > + lockdep_assert_held(&kprobe_mutex);
> > +
> > + scoped_guard(cpus_read_lock) {
> > + guard(mutex)(&text_mutex);
> > +
> > + /* Optimization never be done when disarmed */
> > + if (!kprobes_all_disarmed && kprobes_allow_optimization &&
> > + !list_empty(&gen->optimizing_list))
> > + arch_optimize_kprobes(&gen->optimizing_list);
> > + }
> > +
> > + /* Free cleaned kprobes after quiescence period */
> > + do_free_cleaned_kprobes(&gen->freeing_list);
> > +
> > + gen->in_flight = false;
> > + WRITE_ONCE(gen->ready, false);
> > +}
> > +
> > +static void optprobe_dispatch_generation(void)
> > +{
> > + struct optprobe_generation *gen;
> > +
> > + lockdep_assert_held(&kprobe_mutex);
> > +
> > + if (!optprobe_can_fire() || !optprobe_has_queued_probes())
> > + return;
> > +
> > + gen = &optprobe_gens[optprobe_cur_gen];
> > +
> > + scoped_guard(cpus_read_lock) {
> > + guard(mutex)(&text_mutex);
> > +
> > + /*
> > + * Unoptimize kprobes and collect cleaned (unused and disarmed)
> > + * kprobes before waiting for quiescence period.
> > + */
> > + do_unoptimize_kprobes(&gen->unoptimizing_list, &gen->freeing_list);
> > + }
> > +
> > + /* Advance cur_gen to the next generation slot */
> > + optprobe_cur_gen = (optprobe_cur_gen + 1) % OPTPROBE_GEN_MAX;
> > +
> > + gen->in_flight = true;
> > + WRITE_ONCE(gen->ready, false);
> > +
> > + call_rcu_tasks(&gen->rcu, optprobe_generation_rcu_cb);
> > +}
>
> Now that kprobe_mutex is dropped during the Tasks RCU grace period, can
> an aggregator probe that was unoptimized but is still in use be freed
> while a task is still preempted inside its detour buffer?
Good catch! Yes, we need to keep tracking the unoptimized but not
freed kprobes until finalize it.
[ ... ]
>
> > @@ -707,12 +812,11 @@ static void wait_for_kprobe_optimizer_locked(void)
> > {
> > lockdep_assert_held(&kprobe_mutex);
> >
> > - while (!list_empty(&optimizing_list) || !list_empty(&unoptimizing_list)) {
> > + while (optprobe_optimizer_busy()) {
> > init_completion(&optimizer_completion);
> > - /*
> > - * Set state to OPTIMIZER_ST_FLUSHING and wake up the thread if it's
> > - * idle. If it's already kicked, it will see the state change.
> > - */
> > + optprobe_flush_requested = true;
> > +
> > + /* Wake up optimizer thread */
> > if (atomic_xchg_acquire(&optimizer_state,
> > OPTIMIZER_ST_FLUSHING) != OPTIMIZER_ST_FLUSHING)
> > wake_up(&kprobe_optimizer_wait);
>
> Andrea Parri raised a concern on 2026-09-24 about a race condition in
> this code (https://lore.kernel.org/all/arTuBodyGqQ0mErI@andreayoga.localdomain/).
Yes, so I pick his patch at first and rebase this on it.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-09-26 2:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 2:23 [PATCH v5 00/13] rcu-tasks: build Tasks RCU on Tasks Trace readers in trampolines Josef Bacik
2026-09-22 2:23 ` [PATCH v5 01/13] entry: Pass pt_regs to irqentry_exit_cond_resched() Josef Bacik
2026-09-22 2:23 ` [PATCH v5 02/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines Josef Bacik
2026-09-22 9:26 ` Frederic Weisbecker
2026-09-22 2:23 ` [PATCH v5 03/13] kprobes: Expose the optprobe jump window to Tasks RCU Josef Bacik
2026-09-22 3:22 ` bot+bpf-ci
2026-09-23 7:45 ` Masami Hiramatsu
2026-09-23 13:51 ` [PATCH] kprobes: Make optprobe optimizer multi-generational and asynchronous Masami Hiramatsu (Google)
2026-09-23 15:12 ` Masami Hiramatsu
2026-09-23 16:58 ` Paul E. McKenney
2026-09-24 0:35 ` Masami Hiramatsu
2026-09-24 9:31 ` Andrea Parri
2026-09-24 16:17 ` bot+bpf-ci
2026-09-26 2:17 ` Masami Hiramatsu [this message]
2026-09-22 2:23 ` [PATCH v5 04/13] ftrace: Mark modules hosting direct-call trampolines for Tasks RCU Josef Bacik
2026-09-22 2:23 ` [PATCH v5 05/13] x86/ftrace: Take a Tasks Trace reader around ftrace_caller's call-out Josef Bacik
2026-09-22 2:23 ` [PATCH v5 06/13] x86/kprobes: Take a Tasks Trace reader in the optprobe template Josef Bacik
2026-09-22 3:22 ` bot+bpf-ci
2026-09-22 2:23 ` [PATCH v5 07/13] bpf, x86: Take a Tasks Trace reader in the trampoline around its call-outs Josef Bacik
2026-09-22 3:22 ` bot+bpf-ci
2026-09-23 2:16 ` Alexei Starovoitov
2026-09-22 2:23 ` [PATCH v5 08/13] arm64: ftrace: Take a Tasks Trace reader around ftrace_caller's call-out Josef Bacik
2026-09-22 2:23 ` [PATCH v5 09/13] bpf, arm64: Take a Tasks Trace reader in the trampoline around its call-outs Josef Bacik
2026-09-22 2:23 ` [PATCH v5 10/13] samples: ftrace: Make the direct-call trampolines Tasks Trace readers Josef Bacik
2026-09-22 3:35 ` bot+bpf-ci
2026-09-22 2:23 ` [PATCH v5 11/13] rcutorture: Make Tasks RCU readers Tasks Trace readers where required Josef Bacik
2026-09-22 2:23 ` [PATCH v5 12/13] rcu-tasks-trace: Assert no reader is held on return to userspace Josef Bacik
2026-09-22 3:11 ` bot+bpf-ci
2026-09-22 2:23 ` [PATCH v5 13/13] x86, arm64: Build Tasks RCU on Tasks Trace readers in trampolines Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260926111729.f580fa6a8eaac448649fc8e3@kernel.org \
--to=mhiramat@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=boqun@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=frederic@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=josef@toxicpanda.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=puranjay@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.