Re: [PATCH] libbpf: kprobe.multi: feedback function counts by kernel traced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 26, 2023 at 6:53 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
>
> On Sun, Jun 25, 2023 at 10:18:16AM +0800, Jackie Liu wrote:
> > From: Jackie Liu <liuyun01@xxxxxxxxxx>
> >
> > When tracking functions through kprobe.multi, the number of tracked
> > functions cannot be directly obtained. Sometimes in order to calculate
> > this value, it is necessary to recalculate according to the pattern in
> > the program. This is unnecessary. It is calculated by libbpf feedback
> > through opts.cnt value, which can save resources. Example at [1].
> >
> > [1] https://github.com/JackieLiu1/ketones/blob/master/src/funccount/funccount.c#L317
> >
> > Signed-off-by: Jackie Liu <liuyun01@xxxxxxxxxx>
> > ---
> >  tools/lib/bpf/libbpf.c | 3 ++-
> >  tools/lib/bpf/libbpf.h | 2 +-
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index fca5d2e412c5..ed3f1202c570 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -10506,7 +10506,7 @@ static void kprobe_multi_resolve_reinit(struct kprobe_multi_resolve *res)
> >  struct bpf_link *
> >  bpf_program__attach_kprobe_multi_opts(const struct bpf_program *prog,
> >                                     const char *pattern,
> > -                                   const struct bpf_kprobe_multi_opts *opts)
> > +                                   struct bpf_kprobe_multi_opts *opts)
> >  {
> >       LIBBPF_OPTS(bpf_link_create_opts, lopts);
> >       struct kprobe_multi_resolve res = {
> > @@ -10582,6 +10582,7 @@ bpf_program__attach_kprobe_multi_opts(const struct bpf_program *prog,
> >       }
> >       link->fd = link_fd;
> >       free(res.addrs);
> > +     OPTS_SET(opts, cnt, res.cnt);
>
> hum I'm not sure it's good idea to use opts for output values
>

We do use opts for output parameters in some cases, but in this case I
think it's not strictly necessary for libbpf to report back on the
number of resolved addresses. If an application really needs it, then
getting it from BPF link info is one way, but I'd argue that an
application should just do its own resolution if this is important for
its logic.


> there's ongoing patchset adding possibility to get this
> info/value via BPF_OBJ_GET_INFO_BY_FD syscall [1]
>
> jirka
>
> [1] https://lore.kernel.org/bpf/20230623141546.3751-1-laoar.shao@xxxxxxxxx/
>
> >       return link;
> >
> >  error:
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index 0b7362397ea3..f860dacc6add 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -527,7 +527,7 @@ struct bpf_kprobe_multi_opts {
> >  LIBBPF_API struct bpf_link *
> >  bpf_program__attach_kprobe_multi_opts(const struct bpf_program *prog,
> >                                     const char *pattern,
> > -                                   const struct bpf_kprobe_multi_opts *opts);
> > +                                   struct bpf_kprobe_multi_opts *opts);
> >
> >  struct bpf_ksyscall_opts {
> >       /* size of this struct, for forward/backward compatibility */
> > --
> > 2.25.1
> >





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux