From: Yonghong Song <yhs@meta.com>
To: Jiri Olsa <jolsa@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Jackie Liu <liu.yun@linux.dev>
Subject: Re: [PATCHv2] ftrace: Show all functions with addresses in available_filter_functions_addrs
Date: Sun, 11 Jun 2023 17:22:29 -0700 [thread overview]
Message-ID: <53a11f31-256d-e7bc-eca5-597571076dc5@meta.com> (raw)
In-Reply-To: <20230611130029.1202298-1-jolsa@kernel.org>
On 6/11/23 6:00 AM, Jiri Olsa wrote:
> Adding new available_filter_functions_addrs file that shows all available
> functions (same as available_filter_functions) together with addresses,
> like:
>
> # cat available_filter_functions_addrs | head
> ffffffff81000770 __traceiter_initcall_level
> ffffffff810007c0 __traceiter_initcall_start
> ffffffff81000810 __traceiter_initcall_finish
> ffffffff81000860 trace_initcall_finish_cb
> ...
>
> Note displayed address is the patch-site address and can differ from
> /proc/kallsyms address.
Could you explain how these addresses will be used in kernel, esp.
since these addresses are different from kallsyms addresses?
Also, if there are multiple same static functions with
different addresses, user space might need to check dwarf or
proposed BTF_KIND_KFUNC (which encode kallsyms addresses)
to find whether entry in available_filter_functions_addrs
to be used. But addresses may not match. How this issue could
be resolved?
>
> It's useful to have address avilable for traceable symbols, so we don't
> need to allways cross check kallsyms with available_filter_functions
> (or the other way around) and have all the data in single file.
>
> For backwards compatibility reasons we can't change the existing
> available_filter_functions file output, but we need to add new file.
>
> Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> Documentation/trace/ftrace.rst | 6 ++++++
> include/linux/ftrace.h | 1 +
> kernel/trace/ftrace.c | 37 ++++++++++++++++++++++++++++++++++
> 3 files changed, 44 insertions(+)
>
> v2 changes:
> - simplified address print [Steven]
> - added doc entry for the new file
>
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index 027437b745a0..e97573e3fc4a 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -324,6 +324,12 @@ of ftrace. Here is a list of some of the key files:
> "set_graph_function", or "set_graph_notrace".
> (See the section "dynamic ftrace" below for more details.)
>
> + available_filter_functions_addrs:
> +
> + Similar to available_filter_functions, but with address displayed
> + for each function. The displayed address is the patch-site address
> + and can differ from /proc/kallsyms address.
> +
> dyn_ftrace_total_info:
>
> This file is for debugging purposes. The number of functions that
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index b23bdd414394..6e372575a8e9 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -633,6 +633,7 @@ enum {
> FTRACE_ITER_MOD = (1 << 5),
> FTRACE_ITER_ENABLED = (1 << 6),
> FTRACE_ITER_TOUCHED = (1 << 7),
> + FTRACE_ITER_ADDRS = (1 << 8),
> };
>
> void arch_ftrace_update_code(int command);
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 764668467155..b24c573934af 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -3861,6 +3861,9 @@ static int t_show(struct seq_file *m, void *v)
> if (!rec)
> return 0;
>
> + if (iter->flags & FTRACE_ITER_ADDRS)
> + seq_printf(m, "%lx ", rec->ip);
> +
> if (print_rec(m, rec->ip)) {
> /* This should only happen when a rec is disabled */
> WARN_ON_ONCE(!(rec->flags & FTRACE_FL_DISABLED));
> @@ -3996,6 +3999,30 @@ ftrace_touched_open(struct inode *inode, struct file *file)
> return 0;
> }
>
> +static int
> +ftrace_avail_addrs_open(struct inode *inode, struct file *file)
> +{
> + struct ftrace_iterator *iter;
> + int ret;
> +
> + ret = security_locked_down(LOCKDOWN_TRACEFS);
> + if (ret)
> + return ret;
> +
> + if (unlikely(ftrace_disabled))
> + return -ENODEV;
> +
> + iter = __seq_open_private(file, &show_ftrace_seq_ops, sizeof(*iter));
> + if (!iter)
> + return -ENOMEM;
> +
> + iter->pg = ftrace_pages_start;
> + iter->flags = FTRACE_ITER_ADDRS;
> + iter->ops = &global_ops;
> +
> + return 0;
> +}
> +
> /**
> * ftrace_regex_open - initialize function tracer filter files
> * @ops: The ftrace_ops that hold the hash filters
> @@ -5916,6 +5943,13 @@ static const struct file_operations ftrace_touched_fops = {
> .release = seq_release_private,
> };
>
> +static const struct file_operations ftrace_avail_addrs_fops = {
> + .open = ftrace_avail_addrs_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = seq_release_private,
> +};
> +
> static const struct file_operations ftrace_filter_fops = {
> .open = ftrace_filter_open,
> .read = seq_read,
> @@ -6377,6 +6411,9 @@ static __init int ftrace_init_dyn_tracefs(struct dentry *d_tracer)
> trace_create_file("available_filter_functions", TRACE_MODE_READ,
> d_tracer, NULL, &ftrace_avail_fops);
>
> + trace_create_file("available_filter_functions_addrs", TRACE_MODE_READ,
> + d_tracer, NULL, &ftrace_avail_addrs_fops);
> +
> trace_create_file("enabled_functions", TRACE_MODE_READ,
> d_tracer, NULL, &ftrace_enabled_fops);
>
next prev parent reply other threads:[~2023-06-12 0:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-11 13:00 Jiri Olsa
2023-06-12 0:22 ` Yonghong Song [this message]
2023-06-12 2:54 ` Steven Rostedt
2023-06-12 2:57 ` Steven Rostedt
2023-06-12 14:49 ` Yonghong Song
2023-06-12 15:02 ` Steven Rostedt
2023-06-12 20:25 ` Jiri Olsa
2023-06-12 23:28 ` Andrii Nakryiko
2023-06-12 23:31 ` Steven Rostedt
2023-06-13 1:22 ` Jackie Liu
2023-06-13 5:04 ` Yonghong Song
2023-06-13 13:36 ` Steven Rostedt
2023-06-13 13:44 ` Jiri Olsa
2023-06-14 14:14 ` Jiri Olsa
2023-06-14 15:12 ` Steven Rostedt
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=53a11f31-256d-e7bc-eca5-597571076dc5@meta.com \
--to=yhs@meta.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=liu.yun@linux.dev \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®