From: Masami Hiramatsu <mhiramat@kernel.org>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>, 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>
Subject: Re: [PATCHv2 bpf-next 1/4] kallsyms: Add kallsyms_lookup_names function
Date: Tue, 26 Apr 2022 19:01:08 +0900 [thread overview]
Message-ID: <20220426190108.d9c76f5ccff52e27dbef21af@kernel.org> (raw)
In-Reply-To: <YmJPcU9dahEatb0f@krava>
Hi Jiri,
Sorry for replying late.
On Fri, 22 Apr 2022 08:47:13 +0200
Jiri Olsa <olsajiri@gmail.com> wrote:
> On Tue, Apr 19, 2022 at 10:26:05AM +0200, Jiri Olsa wrote:
>
> SNIP
>
> > > > +static int kallsyms_callback(void *data, const char *name,
> > > > + struct module *mod, unsigned long addr)
> > > > +{
> > > > + struct kallsyms_data *args = data;
> > > > +
> > > > + if (!bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp))
> > > > + return 0;
> > > > +
> > > > + addr = ftrace_location(addr);
> > > > + if (!addr)
> > > > + return 0;
> > >
> > > Ooops, wait. Did you do this last version? I missed this point.
> > > This changes the meanings of the kernel function.
> >
> > yes, it was there before ;-) and you're right.. so some archs can
> > return different address, I did not realize that
> >
> > >
> > > > +
> > > > + args->addrs[args->found++] = addr;
> > > > + return args->found == args->cnt ? 1 : 0;
> > > > +}
> > > > +
> > > > +/**
> > > > + * kallsyms_lookup_names - Lookup addresses for array of symbols
> > >
> > > More correctly "Lookup 'ftraced' addresses for array of sorted symbols", right?
> > >
> > > I'm not sure, we can call it as a 'kallsyms' API, since this is using
> > > kallsyms but doesn't return symbol address, but ftrace address.
> > > I think this name misleads user to expect returning symbol address.
> > >
> > > > + *
> > > > + * @syms: array of symbols pointers symbols to resolve, must be
> > > > + * alphabetically sorted
> > > > + * @cnt: number of symbols/addresses in @syms/@addrs arrays
> > > > + * @addrs: array for storing resulting addresses
> > > > + *
> > > > + * This function looks up addresses for array of symbols provided in
> > > > + * @syms array (must be alphabetically sorted) and stores them in
> > > > + * @addrs array, which needs to be big enough to store at least @cnt
> > > > + * addresses.
> > >
> > > Hmm, sorry I changed my mind. I rather like to expose kallsyms_on_each_symbol()
> > > and provide this API from fprobe or ftrace, because this returns ftrace address
> > > and thus this is only used from fprobe.
> >
> > ok, so how about:
> >
> > int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
>
> quick question.. is it ok if it stays in kalsyms.c object?
I think if this is for the ftrace API, I think it should be in the ftrace.c, and
it can remove unneeded #ifdefs in C code.
>
> so we don't need to expose kallsyms_on_each_symbol,
> and it stays in 'kalsyms' place
We don't need to expose it to modules, but just make it into a global scope.
I don't think that doesn't cause a problem.
Thank you,
>
> jirka
>
>
>
> diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
> index ce1bd2fbf23e..177e0b13c8c5 100644
> --- a/include/linux/kallsyms.h
> +++ b/include/linux/kallsyms.h
> @@ -72,6 +72,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, struct module *,
> #ifdef CONFIG_KALLSYMS
> /* Lookup the address for a symbol. Returns 0 if not found. */
> unsigned long kallsyms_lookup_name(const char *name);
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
>
> extern int kallsyms_lookup_size_offset(unsigned long addr,
> unsigned long *symbolsize,
> @@ -103,6 +104,11 @@ static inline unsigned long kallsyms_lookup_name(const char *name)
> return 0;
> }
>
> +static inline int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs);
> +{
> + return -ERANGE;
> +}
> +
> static inline int kallsyms_lookup_size_offset(unsigned long addr,
> unsigned long *symbolsize,
> unsigned long *offset)
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index 79f2eb617a62..1e7136a765a9 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -29,6 +29,7 @@
> #include <linux/compiler.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
> +#include <linux/bsearch.h>
>
> /*
> * These will be re-linked against their real values
> @@ -228,7 +229,7 @@ unsigned long kallsyms_lookup_name(const char *name)
> return module_kallsyms_lookup_name(name);
> }
>
> -#ifdef CONFIG_LIVEPATCH
> +#if defined(CONFIG_LIVEPATCH) || defined(CONFIG_FPROBE)
> /*
> * Iterate over all symbols in vmlinux. For symbols from modules use
> * module_kallsyms_on_each_symbol instead.
> @@ -572,6 +573,73 @@ int sprint_backtrace_build_id(char *buffer, unsigned long address)
> return __sprint_symbol(buffer, address, -1, 1, 1);
> }
>
> +#ifdef CONFIG_FPROBE
> +static int symbols_cmp(const void *a, const void *b)
> +{
> + const char **str_a = (const char **) a;
> + const char **str_b = (const char **) b;
> +
> + return strcmp(*str_a, *str_b);
> +}
> +
> +struct kallsyms_data {
> + unsigned long *addrs;
> + const char **syms;
> + size_t cnt;
> + size_t found;
> +};
> +
> +static int kallsyms_callback(void *data, const char *name,
> + struct module *mod, unsigned long addr)
> +{
> + struct kallsyms_data *args = data;
> +
> + if (!bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp))
> + return 0;
> +
> + addr = ftrace_location(addr);
> + if (!addr)
> + return 0;
> +
> + args->addrs[args->found++] = addr;
> + return args->found == args->cnt ? 1 : 0;
> +}
> +
> +/**
> + * ftrace_lookup_symbols - Lookup addresses for array of symbols
> + *
> + * @sorted_syms: array of symbols pointers symbols to resolve,
> + * must be alphabetically sorted
> + * @cnt: number of symbols/addresses in @syms/@addrs arrays
> + * @addrs: array for storing resulting addresses
> + *
> + * This function looks up addresses for array of symbols provided in
> + * @syms array (must be alphabetically sorted) and stores them in
> + * @addrs array, which needs to be big enough to store at least @cnt
> + * addresses.
> + *
> + * This function returns 0 if all provided symbols are found,
> + * -ESRCH otherwise.
> + */
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs)
> +{
> + struct kallsyms_data args;
> +
> + args.addrs = addrs;
> + args.syms = sorted_syms;
> + args.cnt = cnt;
> + args.found = 0;
> + kallsyms_on_each_symbol(kallsyms_callback, &args);
> +
> + return args.found == args.cnt ? 0 : -ESRCH;
> +}
> +#else
> +int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *addrs)
> +{
> + return -ERANGE;
> +}
> +#endif /* CONFIG_FPROBE */
> +
> /* To avoid using get_symbol_offset for every symbol, we carry prefix along. */
> struct kallsym_iter {
> loff_t pos;
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2022-04-26 10:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 12:48 [PATCHv2 bpf-next 0/4] bpf: Speed up symbol resolving in kprobe multi link Jiri Olsa
2022-04-18 12:48 ` [PATCHv2 bpf-next 1/4] kallsyms: Add kallsyms_lookup_names function Jiri Olsa
2022-04-18 14:35 ` Masami Hiramatsu
2022-04-19 8:26 ` Jiri Olsa
2022-04-22 6:47 ` Jiri Olsa
2022-04-26 10:01 ` Masami Hiramatsu [this message]
2022-04-26 12:27 ` Jiri Olsa
2022-04-26 16:03 ` Masami Hiramatsu
2022-04-18 12:48 ` [PATCHv2 bpf-next 2/4] fprobe: Resolve symbols with kallsyms_lookup_names Jiri Olsa
2022-04-18 14:39 ` Masami Hiramatsu
2022-04-18 12:48 ` [PATCHv2 bpf-next 3/4] bpf: Resolve symbols with kallsyms_lookup_names for kprobe multi link Jiri Olsa
2022-04-20 21:49 ` Andrii Nakryiko
2022-04-21 6:49 ` Jiri Olsa
2022-04-18 12:48 ` [PATCHv2 bpf-next 4/4] selftests/bpf: Add attach bench test Jiri Olsa
2022-04-20 21:56 ` Andrii Nakryiko
2022-04-21 6:56 ` 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=20220426190108.d9c76f5ccff52e27dbef21af@kernel.org \
--to=mhiramat@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olsajiri@gmail.com \
--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 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.