All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <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>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH bpf-next 2/3] ftrace: Keep address offset in ftrace_lookup_symbols
Date: Fri, 3 Jun 2022 12:16:53 +0200	[thread overview]
Message-ID: <YpnfldPKcEqesioK@krava> (raw)
In-Reply-To: <CAEf4BzbfbPA-U+GObZy2cEZOn9qAHqRmKtKq-rPOVM=_+DGVww@mail.gmail.com>

On Thu, Jun 02, 2022 at 03:52:03PM -0700, Andrii Nakryiko wrote:
> On Fri, May 27, 2022 at 1:56 PM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > We want to store the resolved address on the same index as
> > the symbol string, because that's the user (bpf kprobe link)
> > code assumption.
> >
> > Also making sure we don't store duplicates that might be
> > present in kallsyms.
> >
> > Fixes: bed0d9a50dac ("ftrace: Add ftrace_lookup_symbols function")
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> >  kernel/trace/ftrace.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index 674add0aafb3..00d0ba6397ed 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -7984,15 +7984,23 @@ static int kallsyms_callback(void *data, const char *name,
> >                              struct module *mod, unsigned long addr)
> >  {
> >         struct kallsyms_data *args = data;
> > +       const char **sym;
> > +       int idx;
> >
> > -       if (!bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp))
> > +       sym = bsearch(&name, args->syms, args->cnt, sizeof(*args->syms), symbols_cmp);
> > +       if (!sym)
> > +               return 0;
> > +
> > +       idx = sym - args->syms;
> > +       if (args->addrs[idx])
> 
> if we have duplicated symbols we won't increment args->found here,
> right? So we won't stop early. But we also don't want to increment
> args->found here because we use it to check that we don't have
> duplicates (in addition to making sure we resolved all the unique
> symbols), right?
> 
> So I wonder if in this situation should we return some error code to
> signify that we encountered symbol duplicate?

hum, this callback is called for each kallsyms symbol and there
are duplicates in /proc/kallsyms.. so even if we have just single
copy of such symbol in args->syms, bsearch will find this single
symbol for all the duplicates in /proc/kallsyms and we will endup
in here.. and it's still fine, we should continue

jirka

> 
> 
> >                 return 0;
> >
> >         addr = ftrace_location(addr);
> >         if (!addr)
> >                 return 0;
> >
> > -       args->addrs[args->found++] = addr;
> > +       args->addrs[idx] = addr;
> > +       args->found++;
> >         return args->found == args->cnt ? 1 : 0;
> >  }
> >
> > @@ -8017,6 +8025,7 @@ int ftrace_lookup_symbols(const char **sorted_syms, size_t cnt, unsigned long *a
> >         struct kallsyms_data args;
> >         int err;
> >
> > +       memset(addrs, 0x0, sizeof(*addrs) * cnt);
> >         args.addrs = addrs;
> >         args.syms = sorted_syms;
> >         args.cnt = cnt;
> > --
> > 2.35.3
> >

  reply	other threads:[~2022-06-03 10:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27 20:56 [PATCH bpf-next 0/3] bpf: Fix cookie values for kprobe multi Jiri Olsa
2022-05-27 20:56 ` [PATCH bpf-next 1/3] selftests/bpf: Shuffle cookies symbols in kprobe multi test Jiri Olsa
2022-05-30  5:37   ` Song Liu
2022-05-27 20:56 ` [PATCH bpf-next 2/3] ftrace: Keep address offset in ftrace_lookup_symbols Jiri Olsa
2022-05-30  5:37   ` Song Liu
2022-05-30  7:31     ` Jiri Olsa
2022-05-30 20:20   ` Daniel Borkmann
2022-06-05 16:55     ` Steven Rostedt
2022-06-02 22:52   ` Andrii Nakryiko
2022-06-03 10:16     ` Jiri Olsa [this message]
2022-06-03 19:12       ` Andrii Nakryiko
2022-06-05 16:51   ` Steven Rostedt
2022-06-06 17:56     ` Jiri Olsa
2022-05-27 20:56 ` [PATCH bpf-next 3/3] bpf: Force cookies array to follow symbols sorting Jiri Olsa
2022-05-30  5:40   ` Song Liu
2022-06-02 23:01   ` Andrii Nakryiko
2022-06-02 23:02     ` Andrii Nakryiko
2022-06-03 10:23       ` Jiri Olsa
2022-06-03 21:56         ` Andrii Nakryiko
2022-06-03 10:18     ` 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=YpnfldPKcEqesioK@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --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 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.