From: Jiri Olsa <olsajiri@gmail.com>
To: Steven Rostedt <rostedt@kernel.org>
Cc: Florent Revest <revest@google.com>,
Mark Rutland <mark.rutland@arm.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Menglong Dong <menglong8.dong@gmail.com>
Subject: Re: [PATCH 2/9] ftrace: Add register_ftrace_direct_hash function
Date: Wed, 24 Sep 2025 16:37:03 +0200 [thread overview]
Message-ID: <aNQCDwYcG0Qo00Vg@krava> (raw)
In-Reply-To: <20250924050415.4aefcb91@batman.local.home>
On Wed, Sep 24, 2025 at 05:04:15AM -0400, Steven Rostedt wrote:
> On Tue, 23 Sep 2025 23:51:40 +0200
> Jiri Olsa <jolsa@kernel.org> wrote:
>
> > Adding register_ftrace_direct_hash function that registers
> > all entries (ip -> direct) provided in hash argument.
> >
> > The difference to current register_ftrace_direct is
> > - hash argument that allows to register multiple ip -> direct
> > entries at once
>
> I'm a bit confused. How is this different? Doesn't
> register_ftrace_direct() register multiple ip -> direct entries at once
> too? But instead of using a passed in hash, it uses the hash from
> within the ftrace_ops.
right, but that assumes that we can touch the hash in ftrace_ops directly,
but register_ftrace_direct_hash semantics is bit different, because it allows
to register new (ip,addr) entries on already 'running' ftrace_ops, in which
case you can't change the ftrace_ops hash directly
>
> > - we can call register_ftrace_direct_hash multiple times on the
> > same ftrace_ops object, becase after first registration with
> > register_ftrace_function_nolock, it uses ftrace_update_ops to
> > update the ftrace_ops object
>
> OK, I don't like the name "register" here. "register" should be for the
> first instance and then it is registered. If you call it multiple times
> on the same ops without "unregister" it should give an error.
>
> Perhaps call this "update_ftrace_direct()" where it can update a direct
> ftrace_ops from?
I agree the 'register' naming is confusing in here.. but we still need to
use 3 functions for register/unregister/modify operations, so perhaps:
update_ftrace_direct_add(ops, hash)
update_ftrace_direct_del(ops, hash)
update_ftrace_direct_mod(ops, hash)
?
>
> >
> > This change will allow us to have simple ftrace_ops for all bpf
> > direct interface users in following changes.
>
> After applying all the patches, I have this:
>
> $ git grep register_ftrace_direct_hash
> include/linux/ftrace.h:int register_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash);
> include/linux/ftrace.h:int unregister_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash);
> include/linux/ftrace.h:int register_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash)
> include/linux/ftrace.h:int unregister_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash)
> kernel/trace/ftrace.c: err = register_ftrace_direct_hash(ops, hash);
> kernel/trace/ftrace.c: err = unregister_ftrace_direct_hash(ops, hash);
> kernel/trace/ftrace.c:int register_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash)
> kernel/trace/ftrace.c:EXPORT_SYMBOL_GPL(register_ftrace_direct_hash);
> kernel/trace/ftrace.c:int unregister_ftrace_direct_hash(struct ftrace_ops *ops, struct ftrace_hash *hash)
> kernel/trace/ftrace.c:EXPORT_SYMBOL_GPL(unregister_ftrace_direct_hash);
>
> Where I do not see it is used outside of ftrace.c. Why is it exported?
I have bpf changes using this that I did not post yet, but even with that
there's probably no reason to export this.. will remove
thanks,
jirka
next prev parent reply other threads:[~2025-09-24 14:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 21:51 [PATCH 0/9] ftrace,bpf: Use single direct ops for bpf trampolines Jiri Olsa
2025-09-23 21:51 ` [PATCH 1/9] ftrace: Make alloc_and_copy_ftrace_hash direct friendly Jiri Olsa
2025-09-23 21:51 ` [PATCH 2/9] ftrace: Add register_ftrace_direct_hash function Jiri Olsa
2025-09-24 9:04 ` Steven Rostedt
2025-09-24 14:37 ` Jiri Olsa [this message]
2025-09-24 15:07 ` Steven Rostedt
2025-09-24 16:00 ` Jiri Olsa
2025-09-23 21:51 ` [PATCH 3/9] ftrace: Add unregister_ftrace_direct_hash function Jiri Olsa
2025-09-23 21:51 ` [PATCH 4/9] ftrace: Add modify_ftrace_direct_hash function Jiri Olsa
2025-09-23 21:51 ` [PATCH 5/9] ftrace: Export some of hash related functions Jiri Olsa
2025-09-23 21:51 ` [PATCH 6/9] ftrace: Use direct hash interface in direct functions Jiri Olsa
2025-09-23 21:51 ` [PATCH 7/9] bpf: Add trampoline ip hash table Jiri Olsa
2025-09-23 21:51 ` [PATCH 8/9] ftrace: Factor ftrace_ops ops_func interface Jiri Olsa
2025-09-23 21:51 ` [PATCH 9/9] bpf, x86: Use single ftrace_ops for direct calls Jiri Olsa
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=aNQCDwYcG0Qo00Vg@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--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=menglong8.dong@gmail.com \
--cc=revest@google.com \
--cc=rostedt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).