Date:   Sun, 3 Apr 2022 21:46:57 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alan Maguire <alan.maguire@...cle.com>,
        Ilya Leoshkevich <iii@...ux.ibm.com>
Cc:     Andrii Nakryiko <andrii@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>, Martin Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        john fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Yucong Sun <sunyucong@...il.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH v5 bpf-next 3/5] libbpf: add auto-attach for uprobes based
 on section name

On Sun, Apr 3, 2022 at 6:14 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Wed, Mar 30, 2022 at 8:27 AM Alan Maguire <alan.maguire@...cle.com> wrote:
> >
> > Now that u[ret]probes can use name-based specification, it makes
> > sense to add support for auto-attach based on SEC() definition.
> > The format proposed is
> >
> >         SEC("u[ret]probe/binary:[raw_offset|[function_name[+offset]]")
> >
> > For example, to trace malloc() in libc:
> >
> >         SEC("uprobe/libc.so.6:malloc")
> >
> > ...or to trace function foo2 in /usr/bin/foo:
> >
> >         SEC("uprobe//usr/bin/foo:foo2")
> >
> > Auto-attach is done for all tasks (pid -1).  prog can be an absolute
> > path or simply a program/library name; in the latter case, we use
> > PATH/LD_LIBRARY_PATH to resolve the full path, falling back to
> > standard locations (/usr/bin:/usr/sbin or /usr/lib64:/usr/lib) if
> > the file is not found via environment-variable specified locations.
> >
> > Signed-off-by: Alan Maguire <alan.maguire@...cle.com>
> > ---
> >  tools/lib/bpf/libbpf.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 72 insertions(+), 2 deletions(-)
> >
>
> [...]
>
> > +static int attach_uprobe(const struct bpf_program *prog, long cookie, struct bpf_link **link)
> > +{
> > +       DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, opts);
> > +       char *func, *probe_name, *func_end;
> > +       char *func_name, binary_path[512];
> > +       unsigned long long raw_offset;
> > +       size_t offset = 0;
> > +       int n;
> > +
> > +       *link = NULL;
> > +
> > +       opts.retprobe = str_has_pfx(prog->sec_name, "uretprobe/");
> > +       if (opts.retprobe)
> > +               probe_name = prog->sec_name + sizeof("uretprobe/") - 1;
> > +       else
> > +               probe_name = prog->sec_name + sizeof("uprobe/") - 1;
>
> I think this will mishandle SEC("uretprobe"), let's fix this in a
> follow up (and see a note about uretprobe selftests)

So I actually fixed it up a little bit to avoid test failure on s390x
arch. But now it's a different problem, complaining about not being
able to resolve libc.so.6. CC'ing Ilya, but I was wondering if it's
better to use more generic "libc.so" instead of "libc.so.6"? Have you
tried that?

We should also probably refactor attach_probe.c selftest to be a
collection of subtest, so that we can blacklist only some subtests.
For now I have to blacklist it entirely on s390x.

>
> > +
> > +       /* handle SEC("u[ret]probe") - format is valid, but auto-attach is impossible. */
> > +       if (strlen(probe_name) == 0) {
> > +               pr_debug("section '%s' is old-style u[ret]probe/function, cannot auto-attach\n",
> > +                        prog->sec_name);
>
> this seems excessive to log this, it's expected situation. The message
> itself is also misleading, SEC("uretprobe") isn't old-style, it's
> valid and supported case. SEC("uretprobe/something") is an error now,
> so that's a different thing (let's improve handling in the follow up).
>
> > +               return 0;
> > +       }
> > +       snprintf(binary_path, sizeof(binary_path), "%s", probe_name);
> > +       /* ':' should be prior to function+offset */
> > +       func_name = strrchr(binary_path, ':');
> > +       if (!func_name) {
> > +               pr_warn("section '%s' missing ':function[+offset]' specification\n",
> > +                       prog->sec_name);
> > +               return -EINVAL;
> > +       }
> > +       func_name[0] = '\0';
> > +       func_name++;
> > +       n = sscanf(func_name, "%m[a-zA-Z0-9_.]+%li", &func, &offset);
> > +       if (n < 1) {
> > +               pr_warn("uprobe name '%s' is invalid\n", func_name);
> > +               return -EINVAL;
> > +       }
>
> I have this feeling that you could have simplified this a bunch with
> just one sscanf. Something along the lines of
> "%m[^/]/%m[^:]:%m[a-zA-Z0-9_.]+%li". If one argument matched (supposed
> to be uprobe or uretprobe), then it is a no-auto-attach case, just
> exit. If two matched -- invalid definition (old-style definition you
> were reporting erroneously above in pr_debug). If 3 matched -- binary
> + func (or abs offset), if 4 matched - binary + func + offset. That
> should cover everything, right?
>
> Please try to do this in a follow up.
>
> > +       if (opts.retprobe && offset != 0) {
> > +               free(func);
> > +               pr_warn("uretprobes do not support offset specification\n");
> > +               return -EINVAL;
> > +       }
> > +
> > +       /* Is func a raw address? */
> > +       errno = 0;
> > +       raw_offset = strtoull(func, &func_end, 0);
> > +       if (!errno && !*func_end) {
> > +               free(func);
> > +               func = NULL;
> > +               offset = (size_t)raw_offset;
> > +       }
> > +       opts.func_name = func;
> > +
> > +       *link = bpf_program__attach_uprobe_opts(prog, -1, binary_path, offset, &opts);
> > +       free(func);
> > +       return 0;
>
> this should have been return libbpf_get_error(*link), fixed it
>
>
> > +}
> > +
> >  struct bpf_link *bpf_program__attach_uprobe(const struct bpf_program *prog,
> >                                             bool retprobe, pid_t pid,
> >                                             const char *binary_path,
> > --
> > 1.8.3.1
> >

Powered by blists - more mailing lists