From: Masami Hiramatsu <mhiramat@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
lkml <linux-kernel@vger.kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
"Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH v2 3/8] rethook: Add a generic return hook
Date: Thu, 13 Jan 2022 22:15:32 +0900 [thread overview]
Message-ID: <20220113221532.c48abf7f56d29ba95dcb0dc6@kernel.org> (raw)
In-Reply-To: <YeAaUN8aUip3MUn8@krava>
On Thu, 13 Jan 2022 13:25:52 +0100
Jiri Olsa <jolsa@redhat.com> wrote:
> On Wed, Jan 12, 2022 at 11:03:22PM +0900, Masami Hiramatsu wrote:
> > Add a return hook framework which hooks the function
> > return. Most of the idea came from the kretprobe, but
> > this is independent from kretprobe.
> > Note that this is expected to be used with other
> > function entry hooking feature, like ftrace, fprobe,
> > adn kprobes. Eventually this will replace the
> > kretprobe (e.g. kprobe + rethook = kretprobe), but
> > at this moment, this is just a additional hook.
>
> this looks similar to the code kretprobe is using now
Yes, I've mostly re-typed the code :)
> would it make sense to incrementaly change current code to provide
> this rethook interface? instead of big switch of current kretprobe
> to kprobe + new rethook interface in future?
Would you mean modifying the kretprobe instance code to provide
similar one, and rename it at some point?
My original idea is to keep the current kretprobe code and build
up the similar one, and switch to it at some point. Actually,
I don't want to change the current kretprobe interface itself,
but the backend will be changed. For example, current kretprobe
has below interface.
struct kretprobe {
struct kprobe kp;
kretprobe_handler_t handler;
kretprobe_handler_t entry_handler;
int maxactive;
int nmissed;
size_t data_size;
struct freelist_head freelist;
struct kretprobe_holder *rph;
};
My idea is switching it to below.
struct kretprobe {
struct kprobe kp;
kretprobe_handler_t handler;
kretprobe_handler_t entry_handler;
int maxactive;
int nmissed;
size_t data_size;
struct rethook *rethook;
};
Of course 'kretprobe_instance' may need to be changed...
struct kretprobe_instance {
struct rethook_node;
char data[];
};
But even though, since there is 'get_kretprobe(ri)' wrapper, user
will be able to access the 'struct kretprobe' from kretprobe_instance
transparently.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2022-01-13 13:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 14:02 [RFC PATCH v2 0/8] fprobe: Introduce fprobe function entry/exit probe Masami Hiramatsu
2022-01-12 14:02 ` [RFC PATCH v2 1/8] ftrace: Add ftrace_set_filter_ips function Masami Hiramatsu
2022-01-12 14:03 ` [RFC PATCH v2 2/8] fprobe: Add ftrace based probe APIs Masami Hiramatsu
2022-01-12 14:03 ` [RFC PATCH v2 3/8] rethook: Add a generic return hook Masami Hiramatsu
2022-01-13 12:25 ` Jiri Olsa
2022-01-13 13:15 ` Masami Hiramatsu [this message]
2022-01-14 15:18 ` Jiri Olsa
2022-01-15 4:39 ` Masami Hiramatsu
2022-01-12 14:03 ` [RFC PATCH v2 4/8] rethook: x86: Add rethook x86 implementation Masami Hiramatsu
2022-01-12 14:03 ` [RFC PATCH v2 5/8] fprobe: Add exit_handler support Masami Hiramatsu
2022-01-12 14:03 ` [RFC PATCH v2 6/8] fprobe: Add sample program for fprobe Masami Hiramatsu
2022-01-12 14:04 ` [RFC PATCH v2 7/8] bpf: Add kprobe link for attaching raw kprobes Masami Hiramatsu
2022-01-12 14:04 ` [RFC PATCH v2 8/8] [DO NOT MERGE] Out-of-tree: Support wildcard symbol option to sample Masami Hiramatsu
2022-01-12 16:01 ` [RFC PATCH v2 0/8] fprobe: Introduce fprobe function entry/exit probe Jiri Olsa
2022-01-13 12:27 ` Jiri Olsa
2022-01-13 13:18 ` Masami Hiramatsu
2022-01-14 14:47 ` Masami Hiramatsu
2022-01-14 15:10 ` Jiri Olsa
2022-01-15 1:02 ` Andrii Nakryiko
2022-01-15 2:11 ` Masami Hiramatsu
2022-01-15 4:52 ` Masami Hiramatsu
2022-01-18 14:25 ` Jiri Olsa
2022-01-18 15:15 ` Masami Hiramatsu
2022-01-15 1:08 ` Andrii Nakryiko
2022-01-18 14:38 ` 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=20220113221532.c48abf7f56d29ba95dcb0dc6@kernel.org \
--to=mhiramat@kernel.org \
--cc=andrii@kernel.org \
--cc=anil.s.keshavamurthy@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--cc=jolsa@redhat.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/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).