All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
Cc: <bpf@vger.kernel.org>, <linux-trace-kernel@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>, <ast@kernel.org>,
	<daniel@iogearbox.net>, <andrii@kernel.org>, <song@kernel.org>,
	<jolsa@kernel.org>, <rostedt@goodmis.org>, <naveen@kernel.org>,
	<davem@davemloft.net>, <mhiramat@kernel.org>,
	<stable@vger.kernel.org>, <linux-open-source@crowdstrike.com>
Subject: Re: [RFC PATCH bpf-next 2/3] kprobes: mark ftrace-based kprobe ops permanent
Date: Thu, 30 Jul 2026 12:01:22 +0900	[thread overview]
Message-ID: <20260730120122.bc7a0daa4b28a8577f9a2038@kernel.org> (raw)
In-Reply-To: <20260729005959.3853865-3-andrey.grodzovsky@crowdstrike.com>

On Tue, 28 Jul 2026 20:59:58 -0400
Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com> wrote:

> kernel.ftrace_enabled=0 silently kills ftrace-based kprobes/kretprobes
> the same way it does BPF trampolines: arm succeeds, the probe stops
> firing with no error, and re-enabling silently restores it. Unlike
> trampolines this is not a regression -- ftrace-based kprobes have
> never carried this protection, so the bug is long-standing.
> 
> kprobe_ftrace_ops/kprobe_ipmodify_ops are shared only among
> ftrace-based kprobe attachers, not with any other tracer, so the same
> unconditional FTRACE_OPS_FL_PERMANENT livepatch already uses applies
> cleanly here too, with no kernel/trace/ftrace.c changes needed.
> 
> Known limitation: kprobe.multi/kretprobe.multi/kprobe.session
> (fprobe-backed, kernel/trace/fprobe.c) are not covered. Entry-only
> fprobes could take the same fix, but return-capturing fprobes route
> through the function-graph tracer's shared subops manager, which is
> also used by unrelated tracers (function_graph, irqsoff, wakeup
> latency, function profiler) -- marking it permanent would block
> ftrace_enabled=0 for those too. Left for a follow-up.
> 

In the another thread, Steve and you agreed to just remove
ftrace_enabled, so I assume we will drop this patch.
But from the kprobes point of view this seems reasonable change.

Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>


Thank you,

> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
> ---
>  kernel/kprobes.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index bfc89083daa9..5a54511eee79 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1122,14 +1122,15 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
>  #endif /* CONFIG_OPTPROBES */
>  
>  #ifdef CONFIG_KPROBES_ON_FTRACE
> +/* Same protection livepatch gives its own ftrace_ops. */
>  static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
>  	.func = kprobe_ftrace_handler,
> -	.flags = FTRACE_OPS_FL_SAVE_REGS,
> +	.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_PERMANENT,
>  };
>  
>  static struct ftrace_ops kprobe_ipmodify_ops __read_mostly = {
>  	.func = kprobe_ftrace_handler,
> -	.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> +	.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY | FTRACE_OPS_FL_PERMANENT,
>  };
>  
>  static int kprobe_ipmodify_enabled;
> -- 
> 2.34.1
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  parent reply	other threads:[~2026-07-30  3:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  0:59 [RFC PATCH bpf-next 0/3] ftrace, kprobes, bpf: mark trampoline/kprobe ftrace_ops permanent Andrey Grodzovsky
2026-07-29  0:59 ` [RFC PATCH bpf-next 1/3] bpf: mark trampoline " Andrey Grodzovsky
2026-07-29 13:29   ` Jiri Olsa
2026-07-29  0:59 ` [RFC PATCH bpf-next 2/3] kprobes: mark ftrace-based kprobe ops permanent Andrey Grodzovsky
2026-07-29  1:39   ` sashiko-bot
2026-07-30  3:01   ` Masami Hiramatsu [this message]
2026-07-29  0:59 ` [RFC PATCH bpf-next 3/3] selftests/bpf: add ftrace_permanent test Andrey Grodzovsky
2026-07-29  1:31   ` sashiko-bot
2026-07-29 13:23   ` Jiri Olsa
2026-07-29 17:16     ` Andrey Grodzovsky
2026-07-29 17:38       ` Steven Rostedt
2026-07-29 14:41 ` [RFC PATCH bpf-next 0/3] ftrace, kprobes, bpf: mark trampoline/kprobe ftrace_ops permanent Steven Rostedt
2026-07-29 15:00   ` Andrey Grodzovsky
2026-07-29 15:31     ` Steven Rostedt
2026-07-29 15:47       ` Linus Torvalds
2026-07-29 17:32         ` Steven Rostedt
2026-07-29 17:53           ` Steven Rostedt
2026-07-29 18:20           ` Andrey Grodzovsky
2026-07-29 19:45             ` Steven Rostedt
2026-07-29 19:48               ` Andrey Grodzovsky

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=20260730120122.bc7a0daa4b28a8577f9a2038@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=andrey.grodzovsky@crowdstrike.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jolsa@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-open-source@crowdstrike.com \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=naveen@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=song@kernel.org \
    --cc=stable@vger.kernel.org \
    /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.