BPF List
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>
Cc: kernel-ci@meta.com, bot+bpf-ci@kernel.org, andrii@kernel.org,
	daniel@iogearbox.net, martin.lau@linux.dev,
	bpf <bpf@vger.kernel.org>, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH v14 00/19] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph
Date: Sat, 14 Sep 2024 10:58:38 +0900	[thread overview]
Message-ID: <20240914105838.73130273fdba9b2abad91201@kernel.org> (raw)
In-Reply-To: <CAEf4BzbJCnmHyb7X+RNqJGdcq0k8hM-MxjC5Lhtq+APgvdB2XQ@mail.gmail.com>

On Fri, 13 Sep 2024 14:16:47 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:

> >
> >  - Change bpf_kprobe_multi_addrs_cmp() to call
> >    ftrace_call_adjust() before comparing. This may take a
> >    cost but find actual entry address.
> 
> too expensive, unnecessary runtime overhead

Indeed.

> >
> >  - (Cached method) when making link->addrs, make a link->adj_addrs
> >    array too, where adj_addrs[i] == ftrace_call_adjust(addrs[i]).
> >
> > Let me try the 3rd one. It may consume more memory but the
> > fastest solution.
> 
> I like the third one as well, but I'm not following why we'd need more memory.
> 
> We can store adjusted addresses in existing link->addrs, and we'll
> need to adjust them to originals (potentially expensively) only in
> bpf_kprobe_multi_link_fill_link_info(). But that's not a hot path, so
> it doesn't matter.

OK, that works well, but let me check it has any side effects.

BTW, I worry about what the user expects for `bpf_get_func_ip()`.

 * u64 bpf_get_func_ip(void *ctx)
 * 	Description
 * 		Get address of the traced function (for tracing and kprobe programs).
 *
 * 		When called for kprobe program attached as uprobe it returns
 * 		probe address for both entry and return uprobe.
 *
 * 	Return
 * 		Address of the traced function for kprobe.
 * 		0 for kprobes placed within the function (not at the entry).
 * 		Address of the probe for uprobe and return uprobe.

This seems expecting to get the function address, not ftrace entry
address. If user expects it returns actual function entry address,
we need to change `get_entry_ip()`(*) as the patch I sent.

If they can accept the address a bit shifted from the entry address,
I think we can change link->addrs.

Jiri, and other BPF users, what you expect and what you want to
have? (what the reason to use this API?)

Thank you,

(*) bpf_get_func_ip() seems to read `run_ctx->entry_ip` which is
set by `get_entry_ip(fentry_ip)`.

> 
> >
> > Thank you,
> >
> > >
> > > which is then checked as
> > >
> > > if ((const void *) addr == &bpf_testmod_fentry_test3)
> > >
> > >
> > > With your patches this doesn't match anymore.
> >
> > It actually enables the fprobe on those architectures, so
> > without my series, those test should be skipped.
> 
> Ok, cool, still, let's fix the issue.
> 
> >
> > Thank you,
> >
> > >
> > >
> > > Hopefully the above gives you some pointers, let me know if you run
> > > into any problems.
> > >
> > > >
> > > > Thank you,
> > > >
> > > > >
> > > > > >
> > > > > > Please note: this email is coming from an unmonitored mailbox. If you have
> > > > > > questions or feedback, please reach out to the Meta Kernel CI team at
> > > > > > kernel-ci@meta.com.
> > > >
> > > >
> > > > --
> > > > Masami Hiramatsu (Google) <mhiramat@kernel.org>
> >
> >
> > --
> > Masami Hiramatsu (Google) <mhiramat@kernel.org>


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

      reply	other threads:[~2024-09-14  1:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 15:08 [PATCH v14 00/19] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph Masami Hiramatsu (Google)
2024-09-12 15:08 ` [PATCH v14 01/19] tracing: Add a comment about ftrace_regs definition Masami Hiramatsu (Google)
2024-09-12 15:08 ` [PATCH v14 02/19] tracing: Rename ftrace_regs_return_value to ftrace_regs_get_return_value Masami Hiramatsu (Google)
2024-09-12 15:08 ` [PATCH v14 03/19] function_graph: Pass ftrace_regs to entryfunc Masami Hiramatsu (Google)
2024-09-12 15:08 ` [PATCH v14 04/19] function_graph: Replace fgraph_ret_regs with ftrace_regs Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 05/19] function_graph: Pass ftrace_regs to retfunc Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 06/19] fprobe: Use ftrace_regs in fprobe entry handler Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 07/19] fprobe: Use ftrace_regs in fprobe exit handler Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 08/19] tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 09/19] tracing: Add ftrace_fill_perf_regs() for perf event Masami Hiramatsu (Google)
2024-09-12 15:09 ` [PATCH v14 10/19] tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS Masami Hiramatsu (Google)
2024-09-12 15:10 ` [PATCH v14 11/19] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled Masami Hiramatsu (Google)
2024-09-12 15:10 ` [PATCH v14 12/19] ftrace: Add CONFIG_HAVE_FTRACE_GRAPH_FUNC Masami Hiramatsu (Google)
2024-09-12 15:10 ` [PATCH v14 13/19] fprobe: Rewrite fprobe on function-graph tracer Masami Hiramatsu (Google)
2024-09-12 15:10 ` [PATCH v14 14/19] tracing: Fix function timing profiler to initialize hashtable Masami Hiramatsu (Google)
2024-09-12 15:10 ` [PATCH v14 15/19] tracing/fprobe: Remove nr_maxactive from fprobe Masami Hiramatsu (Google)
2024-09-12 15:11 ` [PATCH v14 16/19] selftests: ftrace: Remove obsolate maxactive syntax check Masami Hiramatsu (Google)
2024-09-12 15:11 ` [PATCH v14 17/19] selftests/ftrace: Add a test case for repeating register/unregister fprobe Masami Hiramatsu (Google)
2024-09-12 15:11 ` [PATCH v14 18/19] Documentation: probes: Update fprobe on function-graph tracer Masami Hiramatsu (Google)
2024-09-12 15:11 ` [PATCH v14 19/19] fgraph: Skip recording calltime/rettime if it is not nneeded Masami Hiramatsu (Google)
2024-09-14 21:53   ` Steven Rostedt
     [not found] ` <0170cd7d95df0583770c385c1e11bd27dfacf618b71b6e723f0952efc0ce9040@mail.kernel.org>
2024-09-12 18:41   ` [PATCH v14 00/19] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph Andrii Nakryiko
2024-09-12 23:54     ` Masami Hiramatsu
2024-09-13  1:55       ` Andrii Nakryiko
2024-09-13  8:59         ` Masami Hiramatsu
2024-09-13 12:45           ` Masami Hiramatsu
2024-09-13 13:49             ` Masami Hiramatsu
2024-09-13 21:23               ` Andrii Nakryiko
2024-09-14  2:10                 ` Masami Hiramatsu
2024-09-13 21:16           ` Andrii Nakryiko
2024-09-14  1:58             ` Masami Hiramatsu [this message]

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=20240914105838.73130273fdba9b2abad91201@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=kernel-ci@meta.com \
    --cc=martin.lau@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox