diff mbox series

[bpf-next,2/3] ftrace: Keep address offset in ftrace_lookup_symbols

Message ID 20220527205611.655282-3-jolsa@kernel.org (mailing list archive)
State Superseded
Delegated to: BPF
Headers show
Series bpf: Fix cookie values for kprobe multi | expand

Checks

Context Check Description
netdev/tree_selection success Clearly marked for bpf-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix success Link
netdev/cover_letter success Series has a cover letter
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 95 this patch: 95
netdev/cc_maintainers warning 2 maintainers not CCed: kpsingh@kernel.org mingo@redhat.com
netdev/build_clang success Errors and warnings before: 36 this patch: 36
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 95 this patch: 95
netdev/checkpatch warning WARNING: line length of 86 exceeds 80 columns
netdev/kdoc success Errors and warnings before: 25 this patch: 25
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-PR fail merge-conflict
bpf/vmtest-bpf-next-VM_Test-1 success Logs for Kernel LATEST on ubuntu-latest with gcc
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Kernel LATEST on ubuntu-latest with llvm-15
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Kernel LATEST on z15 with gcc

Commit Message

Jiri Olsa May 27, 2022, 8:56 p.m. UTC
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(-)

Comments

Song Liu May 30, 2022, 5:37 a.m. UTC | #1
> On 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>

Acked-by: Song Liu <songliubraving@fb.com>

BTW, I guess this set should apply to bpf tree?
Jiri Olsa May 30, 2022, 7:31 a.m. UTC | #2
On Mon, May 30, 2022 at 05:37:49AM +0000, Song Liu wrote:
> 
> 
> > On 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>
> 
> Acked-by: Song Liu <songliubraving@fb.com>
> 
> BTW, I guess this set should apply to bpf tree? 
> 

ah right, I checked and it still applies on bpf/master,
please let me know if I need to resend without 'bpf-next'

thanks,
jirka
Daniel Borkmann May 30, 2022, 8:20 p.m. UTC | #3
On 5/27/22 10:56 PM, Jiri Olsa 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(-)

Steven / Masami, would be great to get an Ack from one of you before applying.

Thanks,
Daniel
Andrii Nakryiko June 2, 2022, 10:52 p.m. UTC | #4
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?


>                 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
>
Jiri Olsa June 3, 2022, 10:16 a.m. UTC | #5
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
> >
Andrii Nakryiko June 3, 2022, 7:12 p.m. UTC | #6
On Fri, Jun 3, 2022 at 3:16 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> 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
>

ah, ok, duplicate kallsyms entries, right, never mind then

> 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
> > >
Steven Rostedt June 5, 2022, 4:51 p.m. UTC | #7
On Fri, 27 May 2022 22:56:10 +0200
Jiri Olsa <jolsa@kernel.org> wrote:

> @@ -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);

Nit, but you don't need the "0x".

-- Steve

>  	args.addrs = addrs;
>  	args.syms = sorted_syms;
>  	args.cnt = cnt;
> --
Steven Rostedt June 5, 2022, 4:55 p.m. UTC | #8
On Mon, 30 May 2022 22:20:12 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:

> On 5/27/22 10:56 PM, Jiri Olsa 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(-)  
> 
> Steven / Masami, would be great to get an Ack from one of you before applying.

I just don't care for the unnecessary "0x" in the memset, but other than that:

Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>

-- Steve
Jiri Olsa June 6, 2022, 5:56 p.m. UTC | #9
On Sun, Jun 05, 2022 at 12:51:22PM -0400, Steven Rostedt wrote:
> On Fri, 27 May 2022 22:56:10 +0200
> Jiri Olsa <jolsa@kernel.org> wrote:
> 
> > @@ -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);
> 
> Nit, but you don't need the "0x".

ok, will remove

thanks,
jirka

> 
> -- Steve
> 
> >  	args.addrs = addrs;
> >  	args.syms = sorted_syms;
> >  	args.cnt = cnt;
> > --
diff mbox series

Patch

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])
 		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;